From dirk.schulz at kinzesberg.de  Sat Mar  1 03:36:58 2008
From: dirk.schulz at kinzesberg.de (Dirk H. Schulz)
Date: Sat, 01 Mar 2008 12:36:58 +0100
Subject: [Xorp-users] BadPeer ...: Area ... not handled by eth0/eth0
In-Reply-To: <3358.1204305597@tigger.icir.org>
References: <3358.1204305597@tigger.icir.org>
Message-ID: <71C7599DC2495C8B29848238@Dirks-MacBook-Pro.local>

Hi Atanu,

many thanks for your patience and guidance. I understand it now (your first 
post, more of the ospf basics), and it works.

Great! Thanks a lot.

Dirk

--On 29. Februar 2008 09:19:57 -0800 Atanu Ghosh <atanu at icsi.berkeley.edu> 
wrote:

> Hi,
>
> OSPF divides the network into areas, each area has a 32 bit area ID, the
> areas are *independent* of subnets.
>
> Areas are structured in a heirarchy, area 0.0.0.0 also called
> the backbone, is the top of the heirarchy and all other areas are
> connected to the backbone (there is an exception but we don't need to
> worry about that here). Figure 6 in RFC 2328
> <http://www.ietf.org/rfc/rfc2328.txt> has an example topology.
>
> In order for neighbouring OSPF routers to communcate they must be
> configured to be in the same area. Every OSPF packet contains a header
> and one of the fields in the header is the area ID. The warning messages
> that you are seeing is OSPF reporting that it was seeing packets on
> eth0 from area 217.64.164.12, but your configuration has eth0 in area
> 0.0.0.0. It looks like your "upstream" has not connected you directly to
> the backbone but has put you in a separate area 217.64.164.12.
>
> If you change your configuration replacing area 0.0.0.0 with
> 217.64.164.12 then you should form adjacencies with your "upstream".
>
>        Atanu.
>
>>>>>> "Dirk" == Dirk H Schulz <dirk.schulz at kinzesberg.de> writes:
>
>     Dirk> Hi Atanu, thanks for helping.
>
>     Dirk> I am not sure I understand you right. You say that on eth0
>     Dirk> ospf packets from a router arrive that is in subnet
>     Dirk> 217.64.164.128? I am logging all traffic at the moment, and
>     Dirk> ospf packets on eth0 arrive only from 217.64.170.233 which is
>     Dirk> the address of the upstream router (I checked on my first
>     Dirk> router).
>
>     Dirk> And I do not understand
>     >> area 217.64.164.128, which in your configuration is area 0.0.0.0
>     Dirk> In my configuration this is area 0.0.0.1 - do you think it
>     Dirk> SHOULD be area 0.0.0.0? I thought that area 0.0.0.0 always is
>     Dirk> the area with the upstream connection.
>
>     Dirk> Thanks again for your help.
>
>     Dirk> Dirk
>
>     Dirk> --On 28. Februar 2008 11:40:13 -0800 Atanu Ghosh
>     Dirk> <atanu at icsi.berkeley.edu> wrote:
>
>     >> Hi,
>     >>
>     >> The message is telling you that OSPF packets are being received
>     >> on eth0/eth0 from a router which is in area 217.64.164.128, which
>     >> in your configuration is area 0.0.0.0. If you change your
>     >> configuration to area 217.64.164.128 you will probably be able to
>     >> peer with your upstream routers.
>     >>
>     >> Atanu.
>     >>
>     >>>>>>> "Dirk" == Dirk H Schulz <dirk.schulz at kinzesberg.de> writes:
>     >>
>     Dirk> Hi Folks, I am new to running routers on my own and new to
>     Dirk> Xorp and OSPF.
>     >>
>     Dirk> I have setup two routers using ospf. They are two
>     Dirk> communication with two upstream routers using ospf as
>     Dirk> well. Now my own routers find each other as neighbors (the do
>     Dirk> not find the upstream routers, but that is a problem I have to
>     Dirk> solve with the upstream provider, I think).
>     >>
>     Dirk> They seem to work, my routers, but both put out the following
>     Dirk> message every few seconds:
>     >>
>     Dirk> BadPeer from line 379 of peer.cc: Area 217.64.164.128 not
>     Dirk> handled by eth0/eth0
>     >>
>     Dirk> I have not found anything relating in the docs, in Google nor
>     Dirk> elsewhere.
>     >>
>     Dirk> 217.64.164.128 is the subnet used for area 0.0.0.1 on
>     Dirk> interface bond0 on both routers. I do not understand why it
>     Dirk> should be handled by eth0 which has a setting of
>     Dirk> 217.64.170.238/29 resp. 217.64.170.230/29.
>     >>
>     Dirk> This is the configuration of one router, the other is nearly
>     Dirk> identical (just other IP addresses):
>     >>  >> interfaces { restore-original-config-on-shutdown: true
>     >> >>
>     >> >> interface eth0 { description: "external (area0) interface" >>
>     >> disable: false default-system-config }
>     >> >>
>     >> >> interface eth1 { description: "inter router interface"
>     >> disable: >> false default-system-config }
>     >> >>
>     >> >> interface bond0 { description: "area1 bonding interface"
>     >> disable: >> false default-system-config } /* interface bond1 {
>     >> description: >> "area2 bonding interface" disable: false
>     >> default-system-config } >> */ }
>     >> >>
>     >> >> fea { unicast-forwarding4 { disable: false forwarding-entries
>     >> { >> retain-on-startup: false retain-on-shutdown: false } } >>
>     >> unicast-forwarding6 { disable: true forwarding-entries { >>
>     >> retain-on-startup: false retain-on-shutdown: false } } }
>     >> >>
>     >> >> protocols { ospf4 { router-id: 217.64.170.238
>     >> >>
>     >> >> area 0.0.0.0 { area-type: "normal" interface eth0 { vif eth0 {
>     >> >> address 217.64.170.238 { priority: 128 hello-interval: 5 >>
>     >> router-dead-interval: 15 interface-cost: 1 retransmit-interval: 2
>     >> >> transit-delay: 1 disable: false } } } interface eth1 { vif
>     >> eth1 { >> address 192.168.11.1 { priority: 128 hello-interval: 5
>     >> >> router-dead-interval: 15 interface-cost: 2
>     >> retransmit-interval: 2 >> transit-delay: 1 disable: false } } } }
>     >> >>
>     >> >> area 0.0.0.1 { area-type: "normal" interface bond0 { vif bond0
>     >> { >> address 217.64.164.129 { priority: 128 hello-interval: 5 >>
>     >> router-dead-interval: 15 interface-cost: 2 retransmit-interval: 2
>     >> >> transit-delay: 1 disable: false } } } } /* area 0.0.0.2 { >>
>     >> area-type: "normal" interface bond1 { vif bond1 { address >>
>     >> 217.64.170.60 } } } */ } }
>     >>
>     Dirk> Any ideas? Every hint or help is appreciated.
>     >>
>     Dirk> Thanks in advance,
>     >>
>     Dirk> Dirk
>     >>
>     Dirk> _______________________________________________ Xorp-users
>     Dirk> mailing list Xorp-users at xorp.org
>     Dirk> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users
>
>
>
>     Dirk> --------------------------------------------------------------
>     Dirk> Dirk H. Schulz IT Systems Service Wiesenweg 12, 85567 Grafing
>     Dirk> Tel. 0 80 92/86 25 68 Fax. 0 80 92/86 25 72
>     Dirk> --------------------------------------------------------------
>     Dirk> Technik vom Feinsten - und das n??tige Tuning
>



--------------------------------------------------------------
Dirk H. Schulz
IT Systems Service
Wiesenweg 12, 85567 Grafing
Tel. 0 80 92/86 25 68
Fax. 0 80 92/86 25 72
--------------------------------------------------------------
Technik vom Feinsten - und das n?tige Tuning


From Florian.Thiessenhusen at admeritia.de  Sat Mar  1 06:51:37 2008
From: Florian.Thiessenhusen at admeritia.de (Florian Thiessenhusen)
Date: Sat, 1 Mar 2008 15:51:37 +0100
Subject: [Xorp-users] static Route 0.0.0.0/0
In-Reply-To: <47C85527.20801@obluda.cz>
References: Message from "Dirk H. Schulz" <dirk.schulz@kinzesberg.de> of
	"Thu,	28 Feb 2008 20:09:11	+0100."
	<E03756E8DDA089E9EF68BA31@Dirks-MacBook-Pro.local>
	<13707.1204227613@tigger.icir.org>
	<D79FDDD8143E7B4CBCDB375A698BDA07011A5F1304@srvmail01.admeritia.lan>,
	<47C85527.20801@obluda.cz>
Message-ID: <D79FDDD8143E7B4CBCDB375A698BDA07011A57F41D@srvmail01.admeritia.lan>

Hi Dan,

thanks for your reply.

"I" means the client.

"Will not work" means, that when i try to ping an external IP Adress, i got the following error:

"Reply from [IP of router]: Destination unreachable."

(Client sends packet to [external IP], it shall be routed via router to the Corporate Firewall (192.168.15.11) but never arrives on it.

The Routiong table of the client has no route to the specific external IP Adress.

This tested a Xorp Config with local networks (that are directly attached to the firewall) - this works without problems.


Thanks,
Florian

________________________________________
Von: xorp-users-bounces at xorp.org [xorp-users-bounces at xorp.org] im Auftrag von Dan Lukes [dan at obluda.cz]
Gesendet: Freitag, 29. Februar 2008 19:55
An: xorp-users at xorp.org
Betreff: Re: [Xorp-users] static Route 0.0.0.0/0

Florian Thiessenhusen napsal/wrote, On 02/29/08 18:46:
> i am testing some very simple Xorp-functions in a testlab.
...
> protocols {
>     static {
>         disable: false
>         route 0.0.0.0/0 {
>             next-hop: 192.168.15.11
>             metric: 1
>         }

> I cannot route into 0.0.0.0/0 (Internet?). It will not work. Where is the failure?

1. who is I ? The client station ? The router ?

2. what mean "it will not work" exactly, in the terms like  "X sends
packet to Y, it shall be routed via Z but never arrive on it" ?

3. what's the route table entry for the outgoing packet in question ?

                                                Dan

_______________________________________________
Xorp-users mailing list
Xorp-users at xorp.org
http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users


From dan at obluda.cz  Sat Mar  1 09:52:47 2008
From: dan at obluda.cz (Dan Lukes)
Date: Sat, 01 Mar 2008 18:52:47 +0100
Subject: [Xorp-users] static Route 0.0.0.0/0
In-Reply-To: <D79FDDD8143E7B4CBCDB375A698BDA07011A57F41D@srvmail01.admeritia.lan>
References: Message from "Dirk H. Schulz" <dirk.schulz@kinzesberg.de> of	"Thu,
	28 Feb 2008
	20:09:11	+0100."	<E03756E8DDA089E9EF68BA31@Dirks-MacBook-Pro.local>	<13707.1204227613@tigger.icir.org>	<D79FDDD8143E7B4CBCDB375A698BDA07011A5F1304@srvmail01.admeritia.lan>,
	<47C85527.20801@obluda.cz>
	<D79FDDD8143E7B4CBCDB375A698BDA07011A57F41D@srvmail01.admeritia.lan>
Message-ID: <47C997EF.4030004@obluda.cz>

> Florian Thiessenhusen napsal/wrote:
>> i am testing some very simple Xorp-functions in a testlab.
> ...
>> protocols {
>>     static {
>>         disable: false
>>         route 0.0.0.0/0 {
>>             next-hop: 192.168.15.11
>>             metric: 1
>>         }
> 
>> I cannot route into 0.0.0.0/0 (Internet?). It will not work. Where is the failure?

> 2. what mean "it will not work" exactly, in the terms like  "X sends
> packet to Y, it shall be routed via Z but never arrive on it" ?

> "Will not work" means, that when i try to ping an external IP Adress, i got the following error:
> "Reply from [IP of router]: Destination unreachable."
> (Client sends packet to [external IP], it shall be routed via router to the Corporate Firewall (192.168.15.11) but never arrives on it.

	Well. So there is no problem with the client but the router.

> 3. what's the route table entry for the outgoing packet in question ?

> The Routiong table of the client has no route to the specific external IP Adress.


	We have problem with the router - so routing table on the client is no 
relevant. You need to consult the routing table on the server. Also, I'm 
not sure what you mena speaking about "specific route entry". We need to 
look for the entry appropriate for the packet in question - whenever 
it's specific or not. So use "route get <destination IP>" or similar 
command (depends on your OS). If there is NO routing entry for the 
destination, then you know why you got "destination unreachable".

						Dan


From atanu at ICSI.Berkeley.EDU  Mon Mar  3 11:23:45 2008
From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh)
Date: Mon, 03 Mar 2008 11:23:45 -0800
Subject: [Xorp-users] OSPF Areas and Linux Route table
In-Reply-To: Message from Sukrit Dasgupta <sd88@drexel.edu> of "Mon,
	03 Mar 2008 13:47:00 EST."
	<DD111E2F-DC57-48CF-AFB9-22C70D9EC179@drexel.edu> 
Message-ID: <45363.1204572225@tigger.icir.org>

Hi,

I'm glad that have you sorted out the problem, from the output that you sent
it did look as if the Cisco was failing to generate Summary-LSAs.

   Atanu.

>>>>> "Sukrit" == Sukrit Dasgupta <sd88 at drexel.edu> writes:

    Sukrit> Hi Atanu,

    Sukrit> Just wanted to update you that the issue got resolved. I was trying to
    Sukrit> do SNMP based automated configurations and for some reason, the Cisco
    Sukrit> routers werent liking the order in which OSPF configurations were
    Sukrit> taking place.

    Sukrit> Thanks for your time!

    Sukrit> Sukrit

    Sukrit> Begin forwarded message:

    Sukrit> From: Sukrit Dasgupta <sd88 at drexel.edu>

    Sukrit> Date: March 1, 2008 10:13:02 PM EST

    Sukrit> To: atanu at icsi.berkeley.edu

    Sukrit> Subject: Re: [Xorp-users] OSPF Areas and Linux Route table

    Sukrit> Hi Atanu,

    Sukrit> Here are the show ospf database output:

    Sukrit> ----------------------------------------------------------------------
    Sukrit> -------- XORP/Linux/Area1/RouterID:12.0.11.2

    Sukrit> show ospf4 database

    Sukrit> OSPF link state database, Area 0.0.0.1

    Sukrit> Type       ID               Adv Rtr           Seq      Age  Opt
    Sukrit> Cksum  Len

    Sukrit> Router  *12.0.11.3        12.0.11.3        0x80000002    86  0x2
    Sukrit> 0xdf0a  36

    Sukrit> Network *12.0.11.3        12.0.11.3        0x80000001    86  0x2
    Sukrit> 0xe9b1  32

    Sukrit> Router   192.168.0.7      192.168.0.7      0x80000002    86  0x22
    Sukrit> 0x64b0  36

    Sukrit> ----------------------------------------------------------------------
    Sukrit> ---------Cisco7200/Area0/RouterID:192.168.0.7

    Sukrit> show ip ospf database

    Sukrit> OSPF Router with ID (192.168.0.7) (Process ID 12)

    Sukrit> Router Link States (Area 1)

    Sukrit> Link ID         ADV Router      Age         Seq#       Checksum Link
    Sukrit> count

    Sukrit> 12.0.11.3       12.0.11.3       305         0x80000002 0xDF0A   1

    Sukrit> 192.168.0.7     192.168.0.7     304         0x80000002 0x64B0   1

    Sukrit> Net Link States (Area 1)

    Sukrit> Link ID         ADV Router      Age         Seq#       Checksum

    Sukrit> 12.0.11.3       12.0.11.3       305         0x80000001 0xE9B1

    Sukrit> OSPF Router with ID (192.168.1.7) (Process ID 14)

    Sukrit> Router Link States (Area 0)

    Sukrit> Link ID         ADV Router      Age         Seq#       Checksum Link
    Sukrit> count

    Sukrit> 192.168.0.1     192.168.0.1     309         0x800006CD 0x33C    4

    Sukrit> 192.168.0.2     192.168.0.2     157         0x800006D1 0xE0C    2

    Sukrit> 192.168.0.3     192.168.0.3     2172        0x800006C8 0xAF82   2

    Sukrit> 192.168.0.4     192.168.0.4     1787        0x800006CB 0x282C   1

    Sukrit> 192.168.1.7     192.168.1.7     146         0x80000006 0xF784   2

    Sukrit> 192.168.1.8     192.168.1.8     270         0x80000002 0x95F8   1

    Sukrit> 192.168.1.10    192.168.1.10    270         0x80000002 0x98AE   1

    Sukrit> Net Link States (Area 0)

    Sukrit> Link ID         ADV Router      Age         Seq#       Checksum

    Sukrit> 14.0.13.111     192.168.0.1     537         0x800006C5 0x4063

    Sukrit> 14.0.23.115     192.168.0.3     383         0x8000013E 0xC15D

    Sukrit> 14.0.24.115     192.168.0.4     1855        0x8000013D 0xBC60

    Sukrit> 14.1.78.2       192.168.1.8     339         0x80000001 0xABD8

    Sukrit> 14.1.107.2      192.168.1.10    338         0x80000001 0x73EF

    Sukrit> ---------------------------------------------
    Sukrit> Cisco7200/Area0/RouterID:192.168.0.10

    Sukrit> show ip ospf database

    Sukrit> OSPF Router with ID (192.168.0.10) (Process ID 16)

    Sukrit> Router Link States (Area 2)

    Sukrit> Link ID         ADV Router      Age         Seq#       Checksum Link
    Sukrit> count

    Sukrit> 16.0.43.2       16.0.43.2       791         0x8000002F 0xEA83   1

    Sukrit> 192.168.0.10    192.168.0.10    222         0x80000003 0x30D4   1

    Sukrit> Net Link States (Area 2)

    Sukrit> Link ID         ADV Router      Age         Seq#       Checksum

    Sukrit> 16.0.43.2       16.0.43.2       228         0x80000001 0x9B95

    Sukrit> OSPF Router with ID (192.168.1.10) (Process ID 14)

    Sukrit> Router Link States (Area 0)

    Sukrit> Link ID         ADV Router      Age         Seq#       Checksum Link
    Sukrit> count

    Sukrit> 192.168.0.1     192.168.0.1     268         0x800006CD 0x33C    4

    Sukrit> 192.168.0.2     192.168.0.2     115         0x800006D1 0xE0C    2

    Sukrit> 192.168.0.3     192.168.0.3     2131        0x800006C8 0xAF82   2

    Sukrit> 192.168.0.4     192.168.0.4     1746        0x800006CB 0x282C   1

    Sukrit> 192.168.1.7     192.168.1.7     104         0x80000006 0xF784   2

    Sukrit> 192.168.1.8     192.168.1.8     229         0x80000002 0x95F8   1

    Sukrit> 192.168.1.10    192.168.1.10    227         0x80000002 0x98AE   1

    Sukrit> Net Link States (Area 0)

    Sukrit> Link ID         ADV Router      Age         Seq#       Checksum

    Sukrit> 14.0.13.111     192.168.0.1     496         0x800006C5 0x4063

    Sukrit> 14.0.23.115     192.168.0.3     342         0x8000013E 0xC15D

    Sukrit> 14.0.24.115     192.168.0.4     1769        0x8000013D 0xBC60

    Sukrit> 14.1.78.2       192.168.1.8     253         0x80000001 0xABD8

    Sukrit> 14.1.107.2      192.168.1.10    251         0x80000001 0x73EF

    Sukrit> -------------------------------------------------------------XORP/Linu
    Sukrit> x/Area1/RouterID:16.0.43.2

    Sukrit> show ospf4 database

    Sukrit> OSPF link state database, Area 0.0.0.2

    Sukrit> Type       ID               Adv Rtr           Seq      Age  Opt
    Sukrit> Cksum  Len

    Sukrit> Router  *16.0.43.2        16.0.43.2        0x80000030   492  0x2
    Sukrit> 0xeb43  36

    Sukrit> Network *16.0.43.2        16.0.43.2        0x80000001   492  0x2
    Sukrit> 0x9b95  32

    Sukrit> Router   192.168.0.10     192.168.0.10     0x80000002   493  0x22
    Sukrit> 0x2338  36

    Sukrit> Thanks,

    Sukrit> Sukrit

    Sukrit> On Mar 1, 2008, at 2:19 PM, Atanu Ghosh wrote:

    Sukrit> Hi,

    Sukrit> The next step is the output of "show ospf4 database" so we can see
    Sukrit> what

    Sukrit> is actually in the database.

    Sukrit> Atanu.

    Sukrit> "Sukrit" == Sukrit Dasgupta <sd88 at drexel.edu> writes:

    Sukrit> Hi Atanu,

    Sukrit> Here are the neighbor tables, the adjacencies are
    Sukrit> correctly formed as

    Sukrit> follows:

    Sukrit> On XORP/Linux 12.0.11.3, show ospf4 neighbor shows:

    Sukrit> Address         Interface             State      ID

    Sukrit> Pri  Dead

    Sukrit> 12.0.11.2        eth0/eth0              Full
    Sukrit> 192.168.1.7

    Sukrit> 1    32

    Sukrit> On Cisco 7200 (Router id 192.168.1.7 )connected to
    Sukrit> 12.0.11.3 and to

    Sukrit> 14.1.107.2, sho ip ospf neighbor shows:

    Sukrit> Neighbor ID     Pri   State           Dead Time   Address

    Sukrit> Interface

    Sukrit> 12.0.11.3       128   FULL/BDR        00:00:38
    Sukrit> 12.0.11.3

    Sukrit> Ethernet2/0

    Sukrit> 192.168.1.10      1   FULL/DR         00:00:37
    Sukrit> 14.1.107.2

    Sukrit> Ethernet2/1

    Sukrit> On Cisco 7200 (Router id 192.168.1.10) connected to
    Sukrit> 14.1.107.1 and to

    Sukrit> 16.0.43.2, sho ip ospf neighbor shows:

    Sukrit> Neighbor ID     Pri   State           Dead Time   Address

    Sukrit> Interface

    Sukrit> 16.0.43.2       128   FULL/BDR        00:00:38
    Sukrit> 16.0.43.2

    Sukrit> Ethernet1/0

    Sukrit> 192.168.1.7       1   FULL/BDR        00:00:31
    Sukrit> 14.1.107.1

    Sukrit> Ethernet1/1

    Sukrit> On XORP/Linux 16.0.43.2, show ospf4 neighbor shows:

    Sukrit> Address         Interface             State      ID

    Sukrit> Pri  Dead

    Sukrit> 16.0.43.110      eth1/eth1              Full
    Sukrit> 192.168.1.10

    Sukrit> 1    39

    Sukrit> So you see, the routers can see each other however, the
    Sukrit> correct area

    Sukrit> information is not propagating through for some reason. A
    Sukrit> similar

    Sukrit> setup used to work earlier before a power failure knocked
    Sukrit> out the

    Sukrit> machines running XORP. I used to validate the
    Sukrit> reach-ability through

    Sukrit> "route -e" on the linux machines.

    Sukrit> I was wondering if its a linux issue and I forgot
    Sukrit> something about

    Sukrit> some flags since its been a long time I played with XORP.
    Sukrit> The

    Sukrit> ip_forward flag is set to 1.

    Sukrit> Thanks,

    Sukrit> Sukrit

    Sukrit> On Mar 1, 2008, at 2:52 AM, Atanu Ghosh wrote:

    Sukrit> Hi,

    Sukrit> The output of "show ospf4 neighbor" would be a useful starting point

    Sukrit> to verify that the adjacencies have been correctly formed.

    Sukrit> Atanu.

    Sukrit> "Sukrit" == Sukrit Dasgupta <sd88 at drexel.edu> writes:

    Sukrit> Hi list, I have a pretty simple setup of 3 areas using

    Sukrit> OSPF:

    Sukrit> 12.0.0.0 (Area1: XORP on Linux)<---------->14.0.0.0

    Sukrit> (Area 0:

    Sukrit> Cisco 7200 Testbed) <-----------------> 16.0.0.0 (Area 2:

    Sukrit> XORP on linux)

    Sukrit> The XORP border routers in Area 1 and Area 2 can ping the

    Sukrit> Cisco ABR routers, but thats about it. The linux route

    Sukrit> table

    Sukrit> shows that only an entry for the corresponding area. So

    Sukrit> for

    Sukrit> example, $route -e on the XORP with router with IP

    Sukrit> 12.0.11.2

    Sukrit> connected to the Cisco 7200 with IP 12.0.11.3 only shows

    Sukrit> Destination Gateway Genmask Flags MSS Window irtt Iface

    Sukrit> 12.0.11.0 * 255.255.255.0 U 0 0 0 eth1

    Sukrit> No OSPF area information is being shared amongst the

    Sukrit> routers.

    Sukrit> Any ideas?

    Sukrit> Thanks in advance Sukrit

    Sukrit> _______________________________________________ Xorp-users

    Sukrit> mailing list Xorp-users at xorp.org

    Sukrit> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-

    Sukrit> users


From expo01 at free.fr  Tue Mar  4 01:16:35 2008
From: expo01 at free.fr (expo01 at free.fr)
Date: Tue, 04 Mar 2008 10:16:35 +0100
Subject: [Xorp-users] value of ttl for ripng
Message-ID: <1204622195.47cd1373d9028@imp.free.fr>


Hi,

We are using Rip and Ripng from Xorp, and we have a problem with a Juniper
router that accepts our Rip messages, but rejects the Ripng messages, pretexting
their "ttl is 1, which is different from 255". We use Xorp 1.5-WIP. I had a very
quick look at Xorp sources, and in the rip/tools directory, I found that
ripng_announcer makes a call to comm_set_ttl(fd, 255), which seems ok. But in
fact, that's true that our Ripng packets are finally issued with a ttl value
equal to 1. Any idea ?

Thanks in advance,

Vincent


From Swati.Deb at bristol.ac.uk  Tue Mar  4 03:03:19 2008
From: Swati.Deb at bristol.ac.uk (Swati Sinha Deb)
Date: Tue, 04 Mar 2008 11:03:19 +0000
Subject: [Xorp-users] Xorp-1.4 Installation Error
Message-ID: <4D76507601E7C88A12CC60B4@[192.168.0.6]>

Hi,

I am trying to install xorp-1.4. But I am getting the following error.

./.libs/libripxrl.a: could not read symbols: Archive has no index; run 
ranlib to add one
collect2: ld returned 1 exit status
gmake[1]: *** [xorp_rip] Error 1

I have GNU ranlib 2.14.90.0.4 20030523. On checking at .libs the sizes of 
the libripxrl.a and other libraries are very small.

I have xorp-1.1 installed and it runs without any problem. Please advice.

Thanks in advance,
Swati




From dan at obluda.cz  Tue Mar  4 03:18:30 2008
From: dan at obluda.cz (Dan Lukes)
Date: Tue, 04 Mar 2008 12:18:30 +0100
Subject: [Xorp-users] Xorp-1.4 Installation Error
In-Reply-To: <4D76507601E7C88A12CC60B4@[192.168.0.6]>
References: <4D76507601E7C88A12CC60B4@[192.168.0.6]>
Message-ID: <47CD3006.5000304@obluda.cz>

Swati Sinha Deb wrote:
> I am trying to install xorp-1.4. But I am getting the following error.
> 
> ./.libs/libripxrl.a: could not read symbols: Archive has no index; run 
> ranlib to add one

	You didn't specified from where you got the instalation source. It 
seems to be damaged. Recompile from scratch then install from newly 
created package.

						Dan


From Swati.Deb at bristol.ac.uk  Tue Mar  4 03:42:53 2008
From: Swati.Deb at bristol.ac.uk (Swati Sinha Deb)
Date: Tue, 04 Mar 2008 11:42:53 +0000
Subject: [Xorp-users] Xorp-1.4 Installation Error
In-Reply-To: <47CD3006.5000304@obluda.cz>
References: <4D76507601E7C88A12CC60B4@[192.168.0.6]>
	<47CD3006.5000304@obluda.cz>
Message-ID: <5CF1B13F62EFBF28C73A16A8@[192.168.0.6]>

Hi Dan,

I downloaded the source from xorp website. I tried doing that few times but 
I keep getting that same error.

Thanks,
Swati

--On 04 March 2008 12:18 +0100 Dan Lukes <dan at obluda.cz> wrote:

> ged.



----------------------
Swati Sinha Deb, Research Fellow
Wireless and Networks Research Laboratory,
Electrical & Electronic Engineering, University of Bristol,
Merchant Venturers Building, Woodland Road,
Bristol BS8 1UB
E-mail: Swati.Deb at bristol.ac.uk
Tel.: +44 (0)117 331 5058


From MANJON at terra.es  Tue Mar  4 04:53:24 2008
From: MANJON at terra.es (MANJON at terra.es)
Date: Tue, 4 Mar 2008 13:53:24 +0100 (MET)
Subject: [Xorp-users] RIP with many peers in the same vlan
Message-ID: <28976215.1204635204874.JavaMail.root@cps1>


Hello Pavlin,

I have a problem in my RIP environment. I have four routers in one vlan, 3 cisco and 1 xorp. 2 ciscos are redistributing routes and 1 cisco and xorp in passive mode.

The passive cisco learn routes from 2 cisco routers but xorp only of one of them. I am using a password md5.

What?s the problem? Is this a limitation of xorp?

Thanks in advance. 

Chema

 

The messages logs:

Mar  4 13:41:29 cpd-fw1 BF-PIM: [ 2008/03/04 13:41:29 INFO xorp_rip RIP ] RIP port vl_400/vl_400/192.174.89.3 authentication failed 192.174.89.252:520 - packet failed authentication (md5): bad sequence number 0x00073265 

The config.boot configuration:

interfaces {
    interface vl_400 {
        description: "data interface"
        disable: false
         /* default-system-config*/
         vif vl_400 {
            disable: false
               address 192.174.89.3 {
                prefix-length: 24
                broadcast: 192.174.89.255
                disable: false
            }
         }

 


    }
    interface vl_3000 {
        description: "data interface"
        disable: false
         /* default-system-config*/
         vif vl_3000 {
            disable: false
               address 189.89.240.200 {
                prefix-length: 24
                broadcast: 189.89.240.255
                disable: false
            }
         }


    }
}

fea {
        unicast-forwarding4 {
                disable: false
}
}

plumbing {
    mfea4 {
        disable: false
        interface vl_400 {
           vif vl_400 {
               disable: false
           }
        }
        interface vl_3000 {
           vif vl_3000 {
               disable: false
           }
        }

        interface register_vif {
            vif register_vif {
                /* note: this vif shoul be always enabled */
                disable: false
            }
        }
        traceoptions {
            flag all {
                disable: true
            }
        }
    }
}

protocols {
    igmp {
        disable: false
        interface vl_400 {
            vif vl_400 {
                disable: false
                /* enable-ip-router-alert-option-check: false */
                /*query-last-member-interval: 1
                query-response-interval: 10*/
                /* robust-count: 2 */
            }
         }
        interface vl_3000 {
            vif vl_3000 {
                disable: false
                /* enable-ip-router-alert-option-check: false */
                /*query-last-member-interval: 1
                query-response-interval: 10*/
                /* robust-count: 2 */
            }
         }
        traceoptions {
            flag all {
                disable: true
            }
        }
    }
}

protocols {
   pimsm4 {
       disable: false
       interface vl_400 {
           vif vl_400 {
               disable: false
               /* dr-priority: 1 */
               /* alternative-subnet 10.40.0.0/16 */
               /* enable-ip-router-alert-option-check: false */
               /* alternative-subnet 10.40.0.0/16 */
           }
       }
       interface vl_3000 {
           vif vl_3000 {
               disable: false
               /* dr-priority: 1 */
               /* alternative-subnet 10.40.0.0/16 */
               /* enable-ip-router-alert-option-check: false */
               /* alternative-subnet 10.40.0.0/16 */
           }
       }
       interface register_vif {
           vif register_vif {
               /* Note: this vif should be always enabled */
               disable: false
           }
       }
       static-rps {
           rp 70.70.71.72 {
               group-prefix 224.0.0.0/4 {
                   /* rp-priority: 192 */
                   /* hash-mask-len: 30 */
               }
           }
       }
       switch-to-spt-threshold {
               disable: false
               interval-sec: 5
               bytes: 5
       }
       traceoptions {
               flag all {
               disable: true
               }
       }
    }
}
protocols {
        rip {
             interface vl_400  {
             vif vl_400  {
                 address 192.174.89.3  {
                 disable: false
                 passive: true
                 authentication {
                  type: "md5"
                  password: "macrolan"
                  }
             }
          }
        }
    }
}

protocols {
        fib2mrib {
                disable: false
        }
}


 

 

 
		 TERRA 

-->


		 TERRA 

-->

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20080304/9c9a219e/attachment-0001.html 

From sd88 at drexel.edu  Mon Mar  3 10:47:00 2008
From: sd88 at drexel.edu (Sukrit Dasgupta)
Date: Mon, 3 Mar 2008 13:47:00 -0500
Subject: [Xorp-users] OSPF Areas and Linux Route table
References: <B382DCCF-58F9-482A-A50D-75A55ED994BC@drexel.edu>
Message-ID: <DD111E2F-DC57-48CF-AFB9-22C70D9EC179@drexel.edu>

Hi Atanu,

Just wanted to update you that the issue got resolved. I was trying  
to do SNMP based automated configurations and for some reason, the  
Cisco routers werent liking the order in which OSPF configurations  
were taking place.

Thanks for your time!
Sukrit


Begin forwarded message:

> From: Sukrit Dasgupta <sd88 at drexel.edu>
> Date: March 1, 2008 10:13:02 PM EST
> To: atanu at icsi.berkeley.edu
> Subject: Re: [Xorp-users] OSPF Areas and Linux Route table
>
> Hi Atanu,
>
> Here are the show ospf database output:
>
> ---------------------------------------------------------------------- 
> -------- XORP/Linux/Area1/RouterID:12.0.11.2
>
>  show ospf4 database
>    OSPF link state database, Area 0.0.0.1
>  Type       ID               Adv Rtr           Seq      Age  Opt   
> Cksum  Len
> Router  *12.0.11.3        12.0.11.3        0x80000002    86  0x2   
> 0xdf0a  36
> Network *12.0.11.3        12.0.11.3        0x80000001    86  0x2   
> 0xe9b1  32
> Router   192.168.0.7      192.168.0.7      0x80000002    86  0x22  
> 0x64b0  36
>
>
> ---------------------------------------------------------------------- 
> ---------Cisco7200/Area0/RouterID:192.168.0.7
>
>
> show ip ospf database
>
>             OSPF Router with ID (192.168.0.7) (Process ID 12)
>
>                 Router Link States (Area 1)
>
> Link ID         ADV Router      Age         Seq#       Checksum  
> Link count
> 12.0.11.3       12.0.11.3       305         0x80000002 0xDF0A   1
> 192.168.0.7     192.168.0.7     304         0x80000002 0x64B0   1
>
>                 Net Link States (Area 1)
>
> Link ID         ADV Router      Age         Seq#       Checksum
> 12.0.11.3       12.0.11.3       305         0x80000001 0xE9B1
>
>             OSPF Router with ID (192.168.1.7) (Process ID 14)
>
>                 Router Link States (Area 0)
>
> Link ID         ADV Router      Age         Seq#       Checksum  
> Link count
> 192.168.0.1     192.168.0.1     309         0x800006CD 0x33C    4
> 192.168.0.2     192.168.0.2     157         0x800006D1 0xE0C    2
> 192.168.0.3     192.168.0.3     2172        0x800006C8 0xAF82   2
> 192.168.0.4     192.168.0.4     1787        0x800006CB 0x282C   1
> 192.168.1.7     192.168.1.7     146         0x80000006 0xF784   2
> 192.168.1.8     192.168.1.8     270         0x80000002 0x95F8   1
> 192.168.1.10    192.168.1.10    270         0x80000002 0x98AE   1
>
>                 Net Link States (Area 0)
>
> Link ID         ADV Router      Age         Seq#       Checksum
> 14.0.13.111     192.168.0.1     537         0x800006C5 0x4063
> 14.0.23.115     192.168.0.3     383         0x8000013E 0xC15D
> 14.0.24.115     192.168.0.4     1855        0x8000013D 0xBC60
> 14.1.78.2       192.168.1.8     339         0x80000001 0xABD8
> 14.1.107.2      192.168.1.10    338         0x80000001 0x73EF
>
>
>
> --------------------------------------------- Cisco7200/Area0/ 
> RouterID:192.168.0.10
>
>
> show ip ospf database
>
>             OSPF Router with ID (192.168.0.10) (Process ID 16)
>
>                 Router Link States (Area 2)
>
> Link ID         ADV Router      Age         Seq#       Checksum  
> Link count
> 16.0.43.2       16.0.43.2       791         0x8000002F 0xEA83   1
> 192.168.0.10    192.168.0.10    222         0x80000003 0x30D4   1
>
>                 Net Link States (Area 2)
>
> Link ID         ADV Router      Age         Seq#       Checksum
> 16.0.43.2       16.0.43.2       228         0x80000001 0x9B95
>
>             OSPF Router with ID (192.168.1.10) (Process ID 14)
>
>                 Router Link States (Area 0)
>
> Link ID         ADV Router      Age         Seq#       Checksum  
> Link count
> 192.168.0.1     192.168.0.1     268         0x800006CD 0x33C    4
> 192.168.0.2     192.168.0.2     115         0x800006D1 0xE0C    2
> 192.168.0.3     192.168.0.3     2131        0x800006C8 0xAF82   2
> 192.168.0.4     192.168.0.4     1746        0x800006CB 0x282C   1
> 192.168.1.7     192.168.1.7     104         0x80000006 0xF784   2
> 192.168.1.8     192.168.1.8     229         0x80000002 0x95F8   1
> 192.168.1.10    192.168.1.10    227         0x80000002 0x98AE   1
>
>                 Net Link States (Area 0)
>
> Link ID         ADV Router      Age         Seq#       Checksum
> 14.0.13.111     192.168.0.1     496         0x800006C5 0x4063
> 14.0.23.115     192.168.0.3     342         0x8000013E 0xC15D
> 14.0.24.115     192.168.0.4     1769        0x8000013D 0xBC60
> 14.1.78.2       192.168.1.8     253         0x80000001 0xABD8
> 14.1.107.2      192.168.1.10    251         0x80000001 0x73EF
>
>
> -------------------------------------------------------------XORP/ 
> Linux/Area1/RouterID:16.0.43.2
>
>
>  show ospf4 database
>    OSPF link state database, Area 0.0.0.2
>  Type       ID               Adv Rtr           Seq      Age  Opt   
> Cksum  Len
> Router  *16.0.43.2        16.0.43.2        0x80000030   492  0x2   
> 0xeb43  36
> Network *16.0.43.2        16.0.43.2        0x80000001   492  0x2   
> 0x9b95  32
> Router   192.168.0.10     192.168.0.10     0x80000002   493  0x22  
> 0x2338  36
>
>
>
> Thanks,
> Sukrit
>
>
>
>
> On Mar 1, 2008, at 2:19 PM, Atanu Ghosh wrote:
>
>> Hi,
>>
>> The next step is the output of "show ospf4 database" so we can see  
>> what
>> is actually in the database.
>>
>>    Atanu.
>>
>>>>>>> "Sukrit" == Sukrit Dasgupta <sd88 at drexel.edu> writes:
>>
>>     Sukrit> Hi Atanu,
>>     Sukrit> Here are the neighbor tables, the adjacencies are  
>> correctly formed as
>>     Sukrit> follows:
>>
>>     Sukrit> On XORP/Linux 12.0.11.3, show ospf4 neighbor shows:
>>     Sukrit> Address         Interface             State      ID
>>     Sukrit> Pri  Dead
>>     Sukrit> 12.0.11.2        eth0/eth0              Full       
>> 192.168.1.7
>>     Sukrit> 1    32
>>
>>     Sukrit> On Cisco 7200 (Router id 192.168.1.7 )connected to  
>> 12.0.11.3 and to
>>     Sukrit> 14.1.107.2, sho ip ospf neighbor shows:
>>     Sukrit> Neighbor ID     Pri   State           Dead Time   Address
>>     Sukrit> Interface
>>     Sukrit> 12.0.11.3       128   FULL/BDR        00:00:38     
>> 12.0.11.3
>>     Sukrit> Ethernet2/0
>>     Sukrit> 192.168.1.10      1   FULL/DR         00:00:37     
>> 14.1.107.2
>>     Sukrit> Ethernet2/1
>>
>>     Sukrit> On Cisco 7200 (Router id 192.168.1.10) connected to  
>> 14.1.107.1 and to
>>     Sukrit> 16.0.43.2, sho ip ospf neighbor shows:
>>     Sukrit> Neighbor ID     Pri   State           Dead Time   Address
>>     Sukrit> Interface
>>     Sukrit> 16.0.43.2       128   FULL/BDR        00:00:38     
>> 16.0.43.2
>>     Sukrit> Ethernet1/0
>>     Sukrit> 192.168.1.7       1   FULL/BDR        00:00:31     
>> 14.1.107.1
>>     Sukrit> Ethernet1/1
>>
>>     Sukrit> On XORP/Linux 16.0.43.2, show ospf4 neighbor shows:
>>     Sukrit> Address         Interface             State      ID
>>     Sukrit> Pri  Dead
>>     Sukrit> 16.0.43.110      eth1/eth1              Full       
>> 192.168.1.10
>>     Sukrit> 1    39
>>
>>
>>     Sukrit> So you see, the routers can see each other however,  
>> the correct area
>>     Sukrit> information is not propagating through for some  
>> reason. A similar
>>     Sukrit> setup used to work earlier before a power failure  
>> knocked out the
>>     Sukrit> machines running XORP. I used to validate the reach- 
>> ability through
>>     Sukrit> "route -e" on the linux machines.
>>     Sukrit> I was wondering if its a linux issue and I forgot  
>> something about
>>     Sukrit> some flags since its been a long time I played with  
>> XORP. The
>>     Sukrit> ip_forward flag is set to 1.
>>
>>     Sukrit> Thanks,
>>     Sukrit> Sukrit
>>
>>     Sukrit> On Mar 1, 2008, at 2:52 AM, Atanu Ghosh wrote:
>>
>>>> Hi,
>>>>
>>>> The output of "show ospf4 neighbor" would be a useful starting  
>>>> point
>>>> to verify that the adjacencies have been correctly formed.
>>>>
>>>> Atanu.
>>>>
>>>>>>>>> "Sukrit" == Sukrit Dasgupta <sd88 at drexel.edu> writes:
>>>>
>>     Sukrit> Hi list, I have a pretty simple setup of 3 areas using
>>>> OSPF:
>>>>
>>>>
>>     Sukrit> 12.0.0.0 (Area1: XORP on Linux)<---------->14.0.0.0
>>>> (Area 0:
>>     Sukrit> Cisco 7200 Testbed) <-----------------> 16.0.0.0 (Area 2:
>>     Sukrit> XORP on linux)
>>>>
>>     Sukrit> The XORP border routers in Area 1 and Area 2 can ping the
>>     Sukrit> Cisco ABR routers, but thats about it. The linux route
>>>> table
>>     Sukrit> shows that only an entry for the corresponding area. So
>>>> for
>>     Sukrit> example, $route -e on the XORP with router with IP
>>>> 12.0.11.2
>>     Sukrit> connected to the Cisco 7200 with IP 12.0.11.3 only shows
>>>>
>>     Sukrit> Destination Gateway Genmask Flags MSS Window irtt Iface
>>     Sukrit> 12.0.11.0 * 255.255.255.0 U 0 0 0 eth1
>>>>
>>     Sukrit> No OSPF area information is being shared amongst the
>>     Sukrit> routers.
>>>>
>>     Sukrit> Any ideas?
>>>>
>>     Sukrit> Thanks in advance Sukrit
>>>>
>>     Sukrit> _______________________________________________ Xorp- 
>> users
>>     Sukrit> mailing list Xorp-users at xorp.org
>>     Sukrit> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-
>>>> users
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20080303/376d2446/attachment-0001.html 

From pavlin at ICSI.Berkeley.EDU  Tue Mar  4 12:18:29 2008
From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov)
Date: Tue, 04 Mar 2008 12:18:29 -0800
Subject: [Xorp-users] Xorp-1.4 Installation Error
In-Reply-To: <5CF1B13F62EFBF28C73A16A8@[192.168.0.6]> 
References: <4D76507601E7C88A12CC60B4@[192.168.0.6]>
	<47CD3006.5000304@obluda.cz>
	<5CF1B13F62EFBF28C73A16A8@[192.168.0.6]>
Message-ID: <200803042018.m24KITbS001676@fruitcake.ICSI.Berkeley.EDU>

Swati Sinha Deb <Swati.Deb at bristol.ac.uk> wrote:

> Hi Dan,
> 
> I downloaded the source from xorp website. I tried doing that few times but 
> I keep getting that same error.

When do you see the problem: while running "gmake" or "gmake install"?

You might also try to use the latest XORP code from anon. CVS.
A number of things have changed in the autoconf/automake setup so
this might eliminate the problem you are seeing.

Regards,
Pavlin

> Thanks,
> Swati
> 
> --On 04 March 2008 12:18 +0100 Dan Lukes <dan at obluda.cz> wrote:
> 
> > ged.
> 
> 
> 
> ----------------------
> Swati Sinha Deb, Research Fellow
> Wireless and Networks Research Laboratory,
> Electrical & Electronic Engineering, University of Bristol,
> Merchant Venturers Building, Woodland Road,
> Bristol BS8 1UB
> E-mail: Swati.Deb at bristol.ac.uk
> Tel.: +44 (0)117 331 5058
> 
> _______________________________________________
> Xorp-users mailing list
> Xorp-users at xorp.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users


From pavlin at ICSI.Berkeley.EDU  Tue Mar  4 13:54:20 2008
From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov)
Date: Tue, 04 Mar 2008 13:54:20 -0800
Subject: [Xorp-users] value of ttl for ripng
In-Reply-To: <1204622195.47cd1373d9028@imp.free.fr> 
References: <1204622195.47cd1373d9028@imp.free.fr>
Message-ID: <200803042154.m24LsKVk021885@fruitcake.ICSI.Berkeley.EDU>

A non-text attachment was scrubbed...
Name: rip_ttl.patch
Type: text/x-c++
Size: 2841 bytes
Desc: not available
Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20080304/841e8cab/attachment.bin 

From expo01 at free.fr  Tue Mar  4 14:12:58 2008
From: expo01 at free.fr (admin galerie)
Date: Tue, 4 Mar 2008 23:12:58 +0100
Subject: [Xorp-users] value of ttl for ripng
In-Reply-To: <200803042154.m24LsKVk021885@fruitcake.ICSI.Berkeley.EDU>
References: <1204622195.47cd1373d9028@imp.free.fr>
	<200803042154.m24LsKVk021885@fruitcake.ICSI.Berkeley.EDU>
Message-ID: <730c07a553edc9c9dafe0abd049b807f@free.fr>

Thanks Pavlin, I will try your patch tomorrow (France time) and give 
you the result as soon as possible.

Vincent

Le 4 mars 08, ? 22:54, Pavlin Radoslavov a ?crit :

> expo01 at free.fr wrote:
>
>> We are using Rip and Ripng from Xorp, and we have a problem with a 
>> Juniper
>> router that accepts our Rip messages, but rejects the Ripng messages, 
>> pretexting
>> their "ttl is 1, which is different from 255". We use Xorp 1.5-WIP. I 
>> had a very
>> quick look at Xorp sources, and in the rip/tools directory, I found 
>> that
>> ripng_announcer makes a call to comm_set_ttl(fd, 255), which seems 
>> ok. But in
>> fact, that's true that our Ripng packets are finally issued with a 
>> ttl value
>> equal to 1. Any idea ?
>
> I think it is a bug in XORP.
> Plese try the following patch, and if it works I will commit it to
> CVS.
>
> Thanks,
> Pavlin
>
> Index: xrl_port_io.cc
> ===================================================================
> RCS file: /usr/local/www/data/cvs/xorp/rip/xrl_port_io.cc,v
> retrieving revision 1.27
> diff -u -p -r1.27 xrl_port_io.cc
> --- xrl_port_io.cc	4 Jan 2008 03:17:34 -0000	1.27
> +++ xrl_port_io.cc	4 Mar 2008 21:50:41 -0000
> @@ -88,12 +88,12 @@ XrlPortIO<IPv4>::request_open_bind_socke
>
>  template <>
>  bool
> -XrlPortIO<IPv4>::request_ttl_one()
> +XrlPortIO<IPv4>::request_ttl()
>  {
>      XrlSocket4V0p1Client cl(&_xr);
>      return cl.send_set_socket_option(
> -		_ss.c_str(), socket_id(), "multicast_ttl", 1,
> -		callback(this, &XrlPortIO<IPv4>::ttl_one_cb));
> +		_ss.c_str(), socket_id(), "multicast_ttl", RIP_TTL,
> +		callback(this, &XrlPortIO<IPv4>::ttl_cb));
>  }
>
>  template <>
> @@ -191,12 +191,12 @@ XrlPortIO<IPv6>::request_open_bind_socke
>
>  template <>
>  bool
> -XrlPortIO<IPv6>::request_ttl_one()
> +XrlPortIO<IPv6>::request_ttl()
>  {
>      XrlSocket6V0p1Client cl(&_xr);
>      return cl.send_set_socket_option(
> -		_ss.c_str(), socket_id(), "multicast_ttl", 1,
> -		callback(this, &XrlPortIO<IPv6>::ttl_one_cb));
> +		_ss.c_str(), socket_id(), "multicast_ttl", RIP_NG_HOP_COUNT,
> +		callback(this, &XrlPortIO<IPv6>::ttl_cb));
>  }
>
>  template <>
> @@ -343,8 +343,8 @@ XrlPortIO<A>::startup_socket()
>  	// If we succeed here the path is:
>  	// request_open_bind_socket()
>  	// -> open_bind_socket_cb()
> -	//    -> request_ttl_one()
> -	//	 -> ttl_one_cb()
> +	//    -> request_ttl()
> +	//	 -> ttl_cb()
>  	//	     -> request_no_loop()
>  	//		-> no_loop_cb()
>  	//		   ->request_socket_join()
> @@ -379,17 +379,17 @@ XrlPortIO<A>::open_bind_socket_cb(const
>      _sid = *psid;
>      socket_manager.add_sockid(_ss, _sid);
>
> -    if (request_ttl_one() == false) {
> -	set_status(SERVICE_FAILED, "Failed requesting ttl/hops of 1.");
> +    if (request_ttl() == false) {
> +	set_status(SERVICE_FAILED, "Failed requesting ttl/hops.");
>      }
>  }
>
>  template <typename A>
>  void
> -XrlPortIO<A>::ttl_one_cb(const XrlError& e)
> +XrlPortIO<A>::ttl_cb(const XrlError& e)
>  {
>      if (e != XrlError::OKAY()) {
> -	XLOG_WARNING("Failed to set ttl/hops to 1");
> +	XLOG_WARNING("Failed to set ttl/hops.");
>      }
>      if (request_no_loop() == false) {
>  	set_status(SERVICE_FAILED,
> Index: xrl_port_io.hh
> ===================================================================
> RCS file: /usr/local/www/data/cvs/xorp/rip/xrl_port_io.hh,v
> retrieving revision 1.13
> diff -u -p -r1.13 xrl_port_io.hh
> --- xrl_port_io.hh	4 Jan 2008 03:17:34 -0000	1.13
> +++ xrl_port_io.hh	4 Mar 2008 21:50:41 -0000
> @@ -94,8 +94,8 @@ private:
>      bool request_open_bind_socket();
>      void open_bind_socket_cb(const XrlError& xe, const string* psid);
>
> -    bool request_ttl_one();
> -    void ttl_one_cb(const XrlError& xe);
> +    bool request_ttl();
> +    void ttl_cb(const XrlError& xe);
>
>      bool request_no_loop();
>      void no_loop_cb(const XrlError& xe);



From pavlin at ICSI.Berkeley.EDU  Tue Mar  4 14:29:20 2008
From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov)
Date: Tue, 04 Mar 2008 14:29:20 -0800
Subject: [Xorp-users] RIP with many peers in the same vlan
In-Reply-To: <28976215.1204635204874.JavaMail.root@cps1> 
References: <28976215.1204635204874.JavaMail.root@cps1>
Message-ID: <200803042229.m24MTKxW028665@fruitcake.ICSI.Berkeley.EDU>

MANJON at terra.es <MANJON at terra.es> wrote:

> 
> Hello Pavlin,
> 
> I have a problem in my RIP environment. I have four routers in one vlan, 3 cisco and 1 xorp. 2 ciscos are redistributing routes and 1 cisco and xorp in passive mode.
> 
> The passive cisco learn routes from 2 cisco routers but xorp only of one of them. I am using a password md5.
> 
> What?s the problem? Is this a limitation of xorp?
> 
> Thanks in advance. 
> 
> Chema
> 
>  
> 
> The messages logs:
> 
> Mar  4 13:41:29 cpd-fw1 BF-PIM: [ 2008/03/04 13:41:29 INFO xorp_rip RIP ] RIP port vl_400/vl_400/192.174.89.3 authentication failed 192.174.89.252:520 - packet failed authentication (md5): bad sequence number 0x00073265 

What XORP version are you using?
In the past there were few bugs related to the MD5 seq. number that
have been fixed in later releases.
Also, your "bad sequence number" message seems to be truncated. It
is suppose to contain "< some_number" part at the end.

Regards,
Pavlin


From Swati.Deb at bristol.ac.uk  Wed Mar  5 01:15:46 2008
From: Swati.Deb at bristol.ac.uk (Swati Sinha Deb)
Date: Wed, 05 Mar 2008 09:15:46 +0000
Subject: [Xorp-users] Xorp-1.4 Installation Error
In-Reply-To: <200803042018.m24KITbS001676@fruitcake.ICSI.Berkeley.EDU>
References: <4D76507601E7C88A12CC60B4@[192.168.0.6]>
	<47CD3006.5000304@obluda.cz> <5CF1B13F62EFBF28C73A16A8@[192.168.0.6]>
	<200803042018.m24KITbS001676@fruitcake.ICSI.Berkeley.EDU>
Message-ID: <3A0D7A38B6287420F900E07A@[192.168.0.6]>

Hi Pavlin,

I used the latest XORP code from CVS and now it works. Thanks for your help.

Regards,
Swati

--On 04 March 2008 12:18 -0800 Pavlin Radoslavov <pavlin at ICSI.Berkeley.EDU> 
wrote:

> Swati Sinha Deb <Swati.Deb at bristol.ac.uk> wrote:
>
>> Hi Dan,
>>
>> I downloaded the source from xorp website. I tried doing that few times
>> but  I keep getting that same error.
>
> When do you see the problem: while running "gmake" or "gmake install"?
>
> You might also try to use the latest XORP code from anon. CVS.
> A number of things have changed in the autoconf/automake setup so
> this might eliminate the problem you are seeing.
>
> Regards,
> Pavlin
>
>> Thanks,
>> Swati
>>
>> --On 04 March 2008 12:18 +0100 Dan Lukes <dan at obluda.cz> wrote:
>>
>> > ged.
>>
>>
>>
>> _______________________________________________
>> Xorp-users mailing list
>> Xorp-users at xorp.org
>> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users





From expo01 at free.fr  Wed Mar  5 12:53:21 2008
From: expo01 at free.fr (admin galerie)
Date: Wed, 5 Mar 2008 21:53:21 +0100
Subject: [Xorp-users] value of ttl for ripng
In-Reply-To: <200803042154.m24LsKVk021885@fruitcake.ICSI.Berkeley.EDU>
References: <1204622195.47cd1373d9028@imp.free.fr>
	<200803042154.m24LsKVk021885@fruitcake.ICSI.Berkeley.EDU>
Message-ID: <d92ab6980a26b8a4a08988876d1f1aaa@free.fr>

Hi Pavlin,

I applied the patch, compiled and tested. It looks ok, in rip the ttl 
is still one, and in ripng the hop limit is now 255. There seems to be 
no regression elsewhere.
You can commit in CVS ! Tell me when/if it's done, so we can be sure 
that a new checkout will bring no regression, please.
Thanks a lot for your quick bug fixing.

Regards,

Vincent
Le 4 mars 08, ? 22:54, Pavlin Radoslavov a ?crit :

> expo01 at free.fr wrote:
>
>> We are using Rip and Ripng from Xorp, and we have a problem with a 
>> Juniper
>> router that accepts our Rip messages, but rejects the Ripng messages, 
>> pretexting
>> their "ttl is 1, which is different from 255". We use Xorp 1.5-WIP. I 
>> had a very
>> quick look at Xorp sources, and in the rip/tools directory, I found 
>> that
>> ripng_announcer makes a call to comm_set_ttl(fd, 255), which seems 
>> ok. But in
>> fact, that's true that our Ripng packets are finally issued with a 
>> ttl value
>> equal to 1. Any idea ?
>
> I think it is a bug in XORP.
> Plese try the following patch, and if it works I will commit it to
> CVS.
>
> Thanks,
> Pavlin
>
> Index: xrl_port_io.cc
> ===================================================================
> RCS file: /usr/local/www/data/cvs/xorp/rip/xrl_port_io.cc,v
> retrieving revision 1.27
> diff -u -p -r1.27 xrl_port_io.cc
> --- xrl_port_io.cc	4 Jan 2008 03:17:34 -0000	1.27
> +++ xrl_port_io.cc	4 Mar 2008 21:50:41 -0000
> @@ -88,12 +88,12 @@ XrlPortIO<IPv4>::request_open_bind_socke
>
>  template <>
>  bool
> -XrlPortIO<IPv4>::request_ttl_one()
> +XrlPortIO<IPv4>::request_ttl()
>  {
>      XrlSocket4V0p1Client cl(&_xr);
>      return cl.send_set_socket_option(
> -		_ss.c_str(), socket_id(), "multicast_ttl", 1,
> -		callback(this, &XrlPortIO<IPv4>::ttl_one_cb));
> +		_ss.c_str(), socket_id(), "multicast_ttl", RIP_TTL,
> +		callback(this, &XrlPortIO<IPv4>::ttl_cb));
>  }
>
>  template <>
> @@ -191,12 +191,12 @@ XrlPortIO<IPv6>::request_open_bind_socke
>
>  template <>
>  bool
> -XrlPortIO<IPv6>::request_ttl_one()
> +XrlPortIO<IPv6>::request_ttl()
>  {
>      XrlSocket6V0p1Client cl(&_xr);
>      return cl.send_set_socket_option(
> -		_ss.c_str(), socket_id(), "multicast_ttl", 1,
> -		callback(this, &XrlPortIO<IPv6>::ttl_one_cb));
> +		_ss.c_str(), socket_id(), "multicast_ttl", RIP_NG_HOP_COUNT,
> +		callback(this, &XrlPortIO<IPv6>::ttl_cb));
>  }
>
>  template <>
> @@ -343,8 +343,8 @@ XrlPortIO<A>::startup_socket()
>  	// If we succeed here the path is:
>  	// request_open_bind_socket()
>  	// -> open_bind_socket_cb()
> -	//    -> request_ttl_one()
> -	//	 -> ttl_one_cb()
> +	//    -> request_ttl()
> +	//	 -> ttl_cb()
>  	//	     -> request_no_loop()
>  	//		-> no_loop_cb()
>  	//		   ->request_socket_join()
> @@ -379,17 +379,17 @@ XrlPortIO<A>::open_bind_socket_cb(const
>      _sid = *psid;
>      socket_manager.add_sockid(_ss, _sid);
>
> -    if (request_ttl_one() == false) {
> -	set_status(SERVICE_FAILED, "Failed requesting ttl/hops of 1.");
> +    if (request_ttl() == false) {
> +	set_status(SERVICE_FAILED, "Failed requesting ttl/hops.");
>      }
>  }
>
>  template <typename A>
>  void
> -XrlPortIO<A>::ttl_one_cb(const XrlError& e)
> +XrlPortIO<A>::ttl_cb(const XrlError& e)
>  {
>      if (e != XrlError::OKAY()) {
> -	XLOG_WARNING("Failed to set ttl/hops to 1");
> +	XLOG_WARNING("Failed to set ttl/hops.");
>      }
>      if (request_no_loop() == false) {
>  	set_status(SERVICE_FAILED,
> Index: xrl_port_io.hh
> ===================================================================
> RCS file: /usr/local/www/data/cvs/xorp/rip/xrl_port_io.hh,v
> retrieving revision 1.13
> diff -u -p -r1.13 xrl_port_io.hh
> --- xrl_port_io.hh	4 Jan 2008 03:17:34 -0000	1.13
> +++ xrl_port_io.hh	4 Mar 2008 21:50:41 -0000
> @@ -94,8 +94,8 @@ private:
>      bool request_open_bind_socket();
>      void open_bind_socket_cb(const XrlError& xe, const string* psid);
>
> -    bool request_ttl_one();
> -    void ttl_one_cb(const XrlError& xe);
> +    bool request_ttl();
> +    void ttl_cb(const XrlError& xe);
>
>      bool request_no_loop();
>      void no_loop_cb(const XrlError& xe);



From Samuel.DeHoyos at NGC.com  Wed Mar  5 13:07:55 2008
From: Samuel.DeHoyos at NGC.com (De Hoyos, Samuel)
Date: Wed, 5 Mar 2008 15:07:55 -0600
Subject: [Xorp-users] Multicast Forwarding
Message-ID: <F45D63E8C730D04F899B1227D5D03FD80DD165@XMBIL101.northgrum.com>

Need some help enabling Multicast forwarding with XORP on a server
running RHEL 5.

We followed all the configuration items on the web and the users manual.

We enabled each interface, fea, mfea, igmp and even pim in the XORP
configuration with our specific information with no luck.

This should be simple but for some reason MC Forwarding is not working. 

Its a simple network with two hosts on either side of a server running
XORP. 

Here is our simple configuration:

mcast source---------------LinuxXORP-------mcast receiver
           ^              ^        ^       ^
           |              |        |       |
       10.100.1.2 	 eth0	 eth1     192.168.10.33
                     10.100.1.3  192.168.10.34

We checked the output of the show igmp group command and can verify that
eth1 is part of the group 225.1.1.2 that we are using. When we check the
show route table ipv4 multicast final table we cannot see the multicast
route being added.

Is there any configuration needed to static routing in the config.boot
file?

We also verify that the source is sending on eth0 to 225.1.1.2 but its
not being forwarded from eth0 to eth1.

Any help would be appreciated.

Sam



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20080305/7a3684de/attachment.html 

From yueli.m at gmail.com  Wed Mar  5 14:19:12 2008
From: yueli.m at gmail.com (Yue Li)
Date: Wed, 5 Mar 2008 17:19:12 -0500
Subject: [Xorp-users] Default value of link-type of a interface of ospf
	router?
Message-ID: <49567c360803051419q76dee40du1c1af10c41ea71b2@mail.gmail.com>

Hi, All

Could anyone tell me what is the default value of the "link-type" of a
interface of OSPF in XORP?

Thanks a lot!


From pavlin at ICSI.Berkeley.EDU  Wed Mar  5 20:59:15 2008
From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov)
Date: Wed, 05 Mar 2008 20:59:15 -0800
Subject: [Xorp-users] value of ttl for ripng
In-Reply-To: <d92ab6980a26b8a4a08988876d1f1aaa@free.fr> 
References: <1204622195.47cd1373d9028@imp.free.fr>
	<200803042154.m24LsKVk021885@fruitcake.ICSI.Berkeley.EDU>
	<d92ab6980a26b8a4a08988876d1f1aaa@free.fr>
Message-ID: <200803060459.m264xFNA015331@fruitcake.ICSI.Berkeley.EDU>

admin galerie <expo01 at free.fr> wrote:

> Hi Pavlin,
> 
> I applied the patch, compiled and tested. It looks ok, in rip the ttl 
> is still one, and in ripng the hop limit is now 255. There seems to be 
> no regression elsewhere.
> You can commit in CVS ! Tell me when/if it's done, so we can be sure 
> that a new checkout will bring no regression, please.
> Thanks a lot for your quick bug fixing.

I've just committed the fix:

Revision  Changes                                Path
1.28      +13 -13;  commitid: 1ca147cf77f941a7;  xorp/rip/xrl_port_io.cc
1.14      +3 -3;  commitid: 1ca147cf77f941a7;    xorp/rip/xrl_port_io.hh

Yes, the TTL for RIPv2 is still 1, because the RIPv2 spec
doesn't say anything on the subject, therefore the generic rule for
link-local multicast applies (TTL = 1).

Regards,
Pavlin

> Regards,
> 
> Vincent
> Le 4 mars 08, ? 22:54, Pavlin Radoslavov a ?crit :
> 
> > expo01 at free.fr wrote:
> >
> >> We are using Rip and Ripng from Xorp, and we have a problem with a 
> >> Juniper
> >> router that accepts our Rip messages, but rejects the Ripng messages, 
> >> pretexting
> >> their "ttl is 1, which is different from 255". We use Xorp 1.5-WIP. I 
> >> had a very
> >> quick look at Xorp sources, and in the rip/tools directory, I found 
> >> that
> >> ripng_announcer makes a call to comm_set_ttl(fd, 255), which seems 
> >> ok. But in
> >> fact, that's true that our Ripng packets are finally issued with a 
> >> ttl value
> >> equal to 1. Any idea ?
> >
> > I think it is a bug in XORP.
> > Plese try the following patch, and if it works I will commit it to
> > CVS.
> >
> > Thanks,
> > Pavlin
> >
> > Index: xrl_port_io.cc
> > ===================================================================
> > RCS file: /usr/local/www/data/cvs/xorp/rip/xrl_port_io.cc,v
> > retrieving revision 1.27
> > diff -u -p -r1.27 xrl_port_io.cc
> > --- xrl_port_io.cc	4 Jan 2008 03:17:34 -0000	1.27
> > +++ xrl_port_io.cc	4 Mar 2008 21:50:41 -0000
> > @@ -88,12 +88,12 @@ XrlPortIO<IPv4>::request_open_bind_socke
> >
> >  template <>
> >  bool
> > -XrlPortIO<IPv4>::request_ttl_one()
> > +XrlPortIO<IPv4>::request_ttl()
> >  {
> >      XrlSocket4V0p1Client cl(&_xr);
> >      return cl.send_set_socket_option(
> > -		_ss.c_str(), socket_id(), "multicast_ttl", 1,
> > -		callback(this, &XrlPortIO<IPv4>::ttl_one_cb));
> > +		_ss.c_str(), socket_id(), "multicast_ttl", RIP_TTL,
> > +		callback(this, &XrlPortIO<IPv4>::ttl_cb));
> >  }
> >
> >  template <>
> > @@ -191,12 +191,12 @@ XrlPortIO<IPv6>::request_open_bind_socke
> >
> >  template <>
> >  bool
> > -XrlPortIO<IPv6>::request_ttl_one()
> > +XrlPortIO<IPv6>::request_ttl()
> >  {
> >      XrlSocket6V0p1Client cl(&_xr);
> >      return cl.send_set_socket_option(
> > -		_ss.c_str(), socket_id(), "multicast_ttl", 1,
> > -		callback(this, &XrlPortIO<IPv6>::ttl_one_cb));
> > +		_ss.c_str(), socket_id(), "multicast_ttl", RIP_NG_HOP_COUNT,
> > +		callback(this, &XrlPortIO<IPv6>::ttl_cb));
> >  }
> >
> >  template <>
> > @@ -343,8 +343,8 @@ XrlPortIO<A>::startup_socket()
> >  	// If we succeed here the path is:
> >  	// request_open_bind_socket()
> >  	// -> open_bind_socket_cb()
> > -	//    -> request_ttl_one()
> > -	//	 -> ttl_one_cb()
> > +	//    -> request_ttl()
> > +	//	 -> ttl_cb()
> >  	//	     -> request_no_loop()
> >  	//		-> no_loop_cb()
> >  	//		   ->request_socket_join()
> > @@ -379,17 +379,17 @@ XrlPortIO<A>::open_bind_socket_cb(const
> >      _sid = *psid;
> >      socket_manager.add_sockid(_ss, _sid);
> >
> > -    if (request_ttl_one() == false) {
> > -	set_status(SERVICE_FAILED, "Failed requesting ttl/hops of 1.");
> > +    if (request_ttl() == false) {
> > +	set_status(SERVICE_FAILED, "Failed requesting ttl/hops.");
> >      }
> >  }
> >
> >  template <typename A>
> >  void
> > -XrlPortIO<A>::ttl_one_cb(const XrlError& e)
> > +XrlPortIO<A>::ttl_cb(const XrlError& e)
> >  {
> >      if (e != XrlError::OKAY()) {
> > -	XLOG_WARNING("Failed to set ttl/hops to 1");
> > +	XLOG_WARNING("Failed to set ttl/hops.");
> >      }
> >      if (request_no_loop() == false) {
> >  	set_status(SERVICE_FAILED,
> > Index: xrl_port_io.hh
> > ===================================================================
> > RCS file: /usr/local/www/data/cvs/xorp/rip/xrl_port_io.hh,v
> > retrieving revision 1.13
> > diff -u -p -r1.13 xrl_port_io.hh
> > --- xrl_port_io.hh	4 Jan 2008 03:17:34 -0000	1.13
> > +++ xrl_port_io.hh	4 Mar 2008 21:50:41 -0000
> > @@ -94,8 +94,8 @@ private:
> >      bool request_open_bind_socket();
> >      void open_bind_socket_cb(const XrlError& xe, const string* psid);
> >
> > -    bool request_ttl_one();
> > -    void ttl_one_cb(const XrlError& xe);
> > +    bool request_ttl();
> > +    void ttl_cb(const XrlError& xe);
> >
> >      bool request_no_loop();
> >      void no_loop_cb(const XrlError& xe);
> 
> 
> _______________________________________________
> Xorp-users mailing list
> Xorp-users at xorp.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users


From pavlin at ICSI.Berkeley.EDU  Wed Mar  5 21:10:08 2008
From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov)
Date: Wed, 05 Mar 2008 21:10:08 -0800
Subject: [Xorp-users] Multicast Forwarding
In-Reply-To: <F45D63E8C730D04F899B1227D5D03FD80DD165@XMBIL101.northgrum.com> 
References: <F45D63E8C730D04F899B1227D5D03FD80DD165@XMBIL101.northgrum.com>
Message-ID: <200803060510.m265A88H017269@fruitcake.ICSI.Berkeley.EDU>

De Hoyos, Samuel <Samuel.DeHoyos at NGC.com> wrote:

> Need some help enabling Multicast forwarding with XORP on a server
> running RHEL 5.
> 
> We followed all the configuration items on the web and the users manual.
> 
> We enabled each interface, fea, mfea, igmp and even pim in the XORP
> configuration with our specific information with no luck.
> 
> This should be simple but for some reason MC Forwarding is not working. 
> 
> Its a simple network with two hosts on either side of a server running
> XORP. 
> 
> Here is our simple configuration:
> 
> mcast source---------------LinuxXORP-------mcast receiver
>            ^              ^        ^       ^
>            |              |        |       |
>        10.100.1.2 	 eth0	 eth1     192.168.10.33
>                      10.100.1.3  192.168.10.34
> 
> We checked the output of the show igmp group command and can verify that
> eth1 is part of the group 225.1.1.2 that we are using. When we check the
> show route table ipv4 multicast final table we cannot see the multicast
> route being added.

The purpose of the "show route table ipv4 multicast final" is
to show the MRIB (Multicast Routing Information Base); i.e., the
unicast routes that are used by PIM for RPF (Reverse Path
Forwarding) check, hence it won't show the multicast routes.

You should use the "show pim join" to see the multicast routes in
PIM-SM.

Some of the most common problems are:

* The TTL of the multicast sender must be larger than 1. By default,
  all multicast packets are transmitted with TTL of 1, therefore
  they won't be forwarded.

* The Cand-RP set in PIM-SM is missing or is incorrect. The simplest
  thing to do is to use a static RP set to one of the IP addresses
  of the XORP box.

* fib2mrib should be part of the configuration.

* There could be some firewall rules in the Linux box that might be
  stopping some of the multicast packets.

Please send your XORP configuration so I can check whether something
is missing/wrong.
Also, please send the output of "show pim join"

Regards,
Pavlin


> Is there any configuration needed to static routing in the config.boot
> file?
> 
> We also verify that the source is sending on eth0 to 225.1.1.2 but its
> not being forwarded from eth0 to eth1.
> 
> Any help would be appreciated.
> 
> Sam
> 
> 
> 
> _______________________________________________
> Xorp-users mailing list
> Xorp-users at xorp.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users


From atanu at ICSI.Berkeley.EDU  Thu Mar  6 01:39:32 2008
From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh)
Date: Thu, 06 Mar 2008 01:39:32 -0800
Subject: [Xorp-users] Default value of link-type of a interface of ospf
	router?
In-Reply-To: Message from "Yue Li" <yueli.m@gmail.com> of "Wed,
	05 Mar 2008 17:19:12 EST."
	<49567c360803051419q76dee40du1c1af10c41ea71b2@mail.gmail.com> 
Message-ID: <42675.1204796372@tigger.icir.org>

Hi,

The default value of "link-type" in OSPF is "broadcast".

Try entering configure mode and run "show -all" you will see all the
default values.

   Atanu.

>>>>> "Yue" == Yue Li <yueli.m at gmail.com> writes:


    Yue> Hi, All Could anyone tell me what is the default value of the
    Yue> "link-type" of a interface of OSPF in XORP?

    Yue> Thanks a lot!

    Yue> _______________________________________________ Xorp-users
    Yue> mailing list Xorp-users at xorp.org
    Yue> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users


From expo01 at free.fr  Thu Mar  6 14:22:20 2008
From: expo01 at free.fr (admin galerie)
Date: Thu, 6 Mar 2008 23:22:20 +0100
Subject: [Xorp-users] value of ttl for ripng
In-Reply-To: <200803060459.m264xFNA015331@fruitcake.ICSI.Berkeley.EDU>
References: <1204622195.47cd1373d9028@imp.free.fr>
	<200803042154.m24LsKVk021885@fruitcake.ICSI.Berkeley.EDU>
	<d92ab6980a26b8a4a08988876d1f1aaa@free.fr>
	<200803060459.m264xFNA015331@fruitcake.ICSI.Berkeley.EDU>
Message-ID: <86f48f24efc5ae8f495f0f30dc32aced@free.fr>

Hi Pavlin,

I have three different questions if you have a little time for me.
The first is about the current CVS repository : yesterday, I applied 
the patch you gave me to the source code I had extracted some days ago. 
The modified files (.cc and .hh) where in the right version (1.27 and 
1.13) so all went well and the result was satisfying. But today, 
knowing that you had commited the fix, we decided to extract again the 
source code from your CVS repository, then recompiled and tested. And 
we have, with this release only, a problem with xorp_fea, which after 
launch dies a horrible death (signal 11, SEGV). Do you know of any 
problem recently appeared in this process ? (xorp_fea in the current 
CVS version is not the same as xorp_fea some days ago)

The second question is about rip : by default, xorp_rip and xorp_ripng 
publish routes with metric=0. This is not accepted by our Juniper peer, 
which says that metric shall be between 1 and 16. So in the policies I 
added in the "then" clause a statement "metric: 1", which fixed the 
Juniper bad mood. Is it ok to fix this problem in such a way ?

And third, in the ripng published routes, I see the following :         
        ::/0      metric: 255
What does it mean ?

Thanks for your support,

Vincent



Le 6 mars 08, ? 05:59, Pavlin Radoslavov a ?crit :

> admin galerie <expo01 at free.fr> wrote:
>
>> Hi Pavlin,
>>
>> I applied the patch, compiled and tested. It looks ok, in rip the ttl
>> is still one, and in ripng the hop limit is now 255. There seems to be
>> no regression elsewhere.
>> You can commit in CVS ! Tell me when/if it's done, so we can be sure
>> that a new checkout will bring no regression, please.
>> Thanks a lot for your quick bug fixing.
>
> I've just committed the fix:
>
> Revision  Changes                                Path
> 1.28      +13 -13;  commitid: 1ca147cf77f941a7;  
> xorp/rip/xrl_port_io.cc
> 1.14      +3 -3;  commitid: 1ca147cf77f941a7;    
> xorp/rip/xrl_port_io.hh
>
> Yes, the TTL for RIPv2 is still 1, because the RIPv2 spec
> doesn't say anything on the subject, therefore the generic rule for
> link-local multicast applies (TTL = 1).
>
> Regards,
> Pavlin
>
>> Regards,
>>
>> Vincent
>> Le 4 mars 08, ? 22:54, Pavlin Radoslavov a ?crit :
>>
>>> expo01 at free.fr wrote:
>>>
>>>> We are using Rip and Ripng from Xorp, and we have a problem with a
>>>> Juniper
>>>> router that accepts our Rip messages, but rejects the Ripng 
>>>> messages,
>>>> pretexting
>>>> their "ttl is 1, which is different from 255". We use Xorp 1.5-WIP. 
>>>> I
>>>> had a very
>>>> quick look at Xorp sources, and in the rip/tools directory, I found
>>>> that
>>>> ripng_announcer makes a call to comm_set_ttl(fd, 255), which seems
>>>> ok. But in
>>>> fact, that's true that our Ripng packets are finally issued with a
>>>> ttl value
>>>> equal to 1. Any idea ?
>>>
>>> I think it is a bug in XORP.
>>> Plese try the following patch, and if it works I will commit it to
>>> CVS.
>>>
>>> Thanks,
>>> Pavlin
>>>
>>> Index: xrl_port_io.cc
>>> ===================================================================
>>> RCS file: /usr/local/www/data/cvs/xorp/rip/xrl_port_io.cc,v
>>> retrieving revision 1.27
>>> diff -u -p -r1.27 xrl_port_io.cc
>>> --- xrl_port_io.cc	4 Jan 2008 03:17:34 -0000	1.27
>>> +++ xrl_port_io.cc	4 Mar 2008 21:50:41 -0000
>>> @@ -88,12 +88,12 @@ XrlPortIO<IPv4>::request_open_bind_socke
>>>
>>>  template <>
>>>  bool
>>> -XrlPortIO<IPv4>::request_ttl_one()
>>> +XrlPortIO<IPv4>::request_ttl()
>>>  {
>>>      XrlSocket4V0p1Client cl(&_xr);
>>>      return cl.send_set_socket_option(
>>> -		_ss.c_str(), socket_id(), "multicast_ttl", 1,
>>> -		callback(this, &XrlPortIO<IPv4>::ttl_one_cb));
>>> +		_ss.c_str(), socket_id(), "multicast_ttl", RIP_TTL,
>>> +		callback(this, &XrlPortIO<IPv4>::ttl_cb));
>>>  }
>>>
>>>  template <>
>>> @@ -191,12 +191,12 @@ XrlPortIO<IPv6>::request_open_bind_socke
>>>
>>>  template <>
>>>  bool
>>> -XrlPortIO<IPv6>::request_ttl_one()
>>> +XrlPortIO<IPv6>::request_ttl()
>>>  {
>>>      XrlSocket6V0p1Client cl(&_xr);
>>>      return cl.send_set_socket_option(
>>> -		_ss.c_str(), socket_id(), "multicast_ttl", 1,
>>> -		callback(this, &XrlPortIO<IPv6>::ttl_one_cb));
>>> +		_ss.c_str(), socket_id(), "multicast_ttl", RIP_NG_HOP_COUNT,
>>> +		callback(this, &XrlPortIO<IPv6>::ttl_cb));
>>>  }
>>>
>>>  template <>
>>> @@ -343,8 +343,8 @@ XrlPortIO<A>::startup_socket()
>>>  	// If we succeed here the path is:
>>>  	// request_open_bind_socket()
>>>  	// -> open_bind_socket_cb()
>>> -	//    -> request_ttl_one()
>>> -	//	 -> ttl_one_cb()
>>> +	//    -> request_ttl()
>>> +	//	 -> ttl_cb()
>>>  	//	     -> request_no_loop()
>>>  	//		-> no_loop_cb()
>>>  	//		   ->request_socket_join()
>>> @@ -379,17 +379,17 @@ XrlPortIO<A>::open_bind_socket_cb(const
>>>      _sid = *psid;
>>>      socket_manager.add_sockid(_ss, _sid);
>>>
>>> -    if (request_ttl_one() == false) {
>>> -	set_status(SERVICE_FAILED, "Failed requesting ttl/hops of 1.");
>>> +    if (request_ttl() == false) {
>>> +	set_status(SERVICE_FAILED, "Failed requesting ttl/hops.");
>>>      }
>>>  }
>>>
>>>  template <typename A>
>>>  void
>>> -XrlPortIO<A>::ttl_one_cb(const XrlError& e)
>>> +XrlPortIO<A>::ttl_cb(const XrlError& e)
>>>  {
>>>      if (e != XrlError::OKAY()) {
>>> -	XLOG_WARNING("Failed to set ttl/hops to 1");
>>> +	XLOG_WARNING("Failed to set ttl/hops.");
>>>      }
>>>      if (request_no_loop() == false) {
>>>  	set_status(SERVICE_FAILED,
>>> Index: xrl_port_io.hh
>>> ===================================================================
>>> RCS file: /usr/local/www/data/cvs/xorp/rip/xrl_port_io.hh,v
>>> retrieving revision 1.13
>>> diff -u -p -r1.13 xrl_port_io.hh
>>> --- xrl_port_io.hh	4 Jan 2008 03:17:34 -0000	1.13
>>> +++ xrl_port_io.hh	4 Mar 2008 21:50:41 -0000
>>> @@ -94,8 +94,8 @@ private:
>>>      bool request_open_bind_socket();
>>>      void open_bind_socket_cb(const XrlError& xe, const string* 
>>> psid);
>>>
>>> -    bool request_ttl_one();
>>> -    void ttl_one_cb(const XrlError& xe);
>>> +    bool request_ttl();
>>> +    void ttl_cb(const XrlError& xe);
>>>
>>>      bool request_no_loop();
>>>      void no_loop_cb(const XrlError& xe);
>>
>>
>> _______________________________________________
>> Xorp-users mailing list
>> Xorp-users at xorp.org
>> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users
>



From Samuel.DeHoyos at NGC.com  Fri Mar  7 03:49:39 2008
From: Samuel.DeHoyos at NGC.com (De Hoyos, Samuel)
Date: Fri, 7 Mar 2008 05:49:39 -0600
Subject: [Xorp-users] Multicast Forwarding
In-Reply-To: <200803060510.m265A88H017269@fruitcake.ICSI.Berkeley.EDU>
References: <F45D63E8C730D04F899B1227D5D03FD80DD165@XMBIL101.northgrum.com>
	<200803060510.m265A88H017269@fruitcake.ICSI.Berkeley.EDU>
Message-ID: <F45D63E8C730D04F899B1227D5D03FD8010C500D@XMBIL101.northgrum.com>

Hello,
It was actually the RHEL 5 firewall that was preventing the forwarding
of multicast. Once we disabled it the multicast traffic was successful
using our original configuration. 

Thanks for your help.

BTW, if anyone is aware of the proper rules that would allow multicast
to work using XORP with a default iptables configuration, please
respond.

Thanks,
Sam De Hoyos 

-----Original Message-----
From: Pavlin Radoslavov [mailto:pavlin at ICSI.Berkeley.EDU] 
Sent: Thursday, March 06, 2008 12:10 AM
To: De Hoyos, Samuel
Cc: xorp-users at xorp.org
Subject: Re: [Xorp-users] Multicast Forwarding 

De Hoyos, Samuel <Samuel.DeHoyos at NGC.com> wrote:

> Need some help enabling Multicast forwarding with XORP on a server 
> running RHEL 5.
> 
> We followed all the configuration items on the web and the users
manual.
> 
> We enabled each interface, fea, mfea, igmp and even pim in the XORP 
> configuration with our specific information with no luck.
> 
> This should be simple but for some reason MC Forwarding is not
working. 
> 
> Its a simple network with two hosts on either side of a server running

> XORP.
> 
> Here is our simple configuration:
> 
> mcast source---------------LinuxXORP-------mcast receiver
>            ^              ^        ^       ^
>            |              |        |       |
>        10.100.1.2 	 eth0	 eth1     192.168.10.33
>                      10.100.1.3  192.168.10.34
> 
> We checked the output of the show igmp group command and can verify 
> that
> eth1 is part of the group 225.1.1.2 that we are using. When we check 
> the show route table ipv4 multicast final table we cannot see the 
> multicast route being added.

The purpose of the "show route table ipv4 multicast final" is to show
the MRIB (Multicast Routing Information Base); i.e., the unicast routes
that are used by PIM for RPF (Reverse Path
Forwarding) check, hence it won't show the multicast routes.

You should use the "show pim join" to see the multicast routes in
PIM-SM.

Some of the most common problems are:

* The TTL of the multicast sender must be larger than 1. By default,
  all multicast packets are transmitted with TTL of 1, therefore
  they won't be forwarded.

* The Cand-RP set in PIM-SM is missing or is incorrect. The simplest
  thing to do is to use a static RP set to one of the IP addresses
  of the XORP box.

* fib2mrib should be part of the configuration.

* There could be some firewall rules in the Linux box that might be
  stopping some of the multicast packets.

Please send your XORP configuration so I can check whether something is
missing/wrong.
Also, please send the output of "show pim join"

Regards,
Pavlin


> Is there any configuration needed to static routing in the config.boot

> file?
> 
> We also verify that the source is sending on eth0 to 225.1.1.2 but its

> not being forwarded from eth0 to eth1.
> 
> Any help would be appreciated.
> 
> Sam
> 
> 
> 
> _______________________________________________
> Xorp-users mailing list
> Xorp-users at xorp.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users


From pavlin at ICSI.Berkeley.EDU  Fri Mar  7 04:23:41 2008
From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov)
Date: Fri, 07 Mar 2008 04:23:41 -0800
Subject: [Xorp-users] value of ttl for ripng
In-Reply-To: <86f48f24efc5ae8f495f0f30dc32aced@free.fr> 
References: <1204622195.47cd1373d9028@imp.free.fr>
	<200803042154.m24LsKVk021885@fruitcake.ICSI.Berkeley.EDU>
	<d92ab6980a26b8a4a08988876d1f1aaa@free.fr>
	<200803060459.m264xFNA015331@fruitcake.ICSI.Berkeley.EDU>
	<86f48f24efc5ae8f495f0f30dc32aced@free.fr>
Message-ID: <200803071223.m27CNfa6012693@fruitcake.ICSI.Berkeley.EDU>

admin galerie <expo01 at free.fr> wrote:

> Hi Pavlin,
> 
> I have three different questions if you have a little time for me.
> The first is about the current CVS repository : yesterday, I applied 
> the patch you gave me to the source code I had extracted some days ago. 
> The modified files (.cc and .hh) where in the right version (1.27 and 
> 1.13) so all went well and the result was satisfying. But today, 
> knowing that you had commited the fix, we decided to extract again the 
> source code from your CVS repository, then recompiled and tested. And 
> we have, with this release only, a problem with xorp_fea, which after 
> launch dies a horrible death (signal 11, SEGV). Do you know of any 
> problem recently appeared in this process ? (xorp_fea in the current 
> CVS version is not the same as xorp_fea some days ago)

Yesterday I committed some changes to the FEA.
I think there was a bug inside those changes, so I temporary
reversed them pending further investigation:

Revision  Changes                              Path
1.58      +5 -7;  commitid: 4e1f47d1305c41a7;  xorp/fea/iftree.cc
1.61      +7 -9;  commitid: 4e1f47d1305c41a7;  xorp/fea/iftree.hh

Please pull again the latest FEA code from CVS and make sure the
above two files are the correct version.

> The second question is about rip : by default, xorp_rip and xorp_ripng 
> publish routes with metric=0. This is not accepted by our Juniper peer, 
> which says that metric shall be between 1 and 16. So in the policies I 
> added in the "then" clause a statement "metric: 1", which fixed the 
> Juniper bad mood. Is it ok to fix this problem in such a way ?

What is your RIP and policy configuration without the above "then"
clause that you use to fix the metric?

If you use a policy like the following, is the RIP/RIPng metric for
connected routes actually advertised as zero?

policy {
    policy-statement export-connected {
        term 100 {
            from {
                protocol: "connected"
            }
        }
    }
}

If this is the case, then this is a bug, so please submit it into
Bugzilla.

In the mean time you could use the "metric: 1" fix in the "then"
clause.

> And third, in the ripng published routes, I see the following :         
>         ::/0      metric: 255
> What does it mean ?

Where do you see it?
Route "::/0" is the default route (the equivalent of 0.0.0.0/0 for
IPv4), so basically the above says that the metric for the default
route is 255.

Regards,
Pavlin

> Thanks for your support,
> 
> Vincent
> 
> 
> 
> Le 6 mars 08, ? 05:59, Pavlin Radoslavov a ?crit :
> 
> > admin galerie <expo01 at free.fr> wrote:
> >
> >> Hi Pavlin,
> >>
> >> I applied the patch, compiled and tested. It looks ok, in rip the ttl
> >> is still one, and in ripng the hop limit is now 255. There seems to be
> >> no regression elsewhere.
> >> You can commit in CVS ! Tell me when/if it's done, so we can be sure
> >> that a new checkout will bring no regression, please.
> >> Thanks a lot for your quick bug fixing.
> >
> > I've just committed the fix:
> >
> > Revision  Changes                                Path
> > 1.28      +13 -13;  commitid: 1ca147cf77f941a7;  
> > xorp/rip/xrl_port_io.cc
> > 1.14      +3 -3;  commitid: 1ca147cf77f941a7;    
> > xorp/rip/xrl_port_io.hh
> >
> > Yes, the TTL for RIPv2 is still 1, because the RIPv2 spec
> > doesn't say anything on the subject, therefore the generic rule for
> > link-local multicast applies (TTL = 1).
> >
> > Regards,
> > Pavlin
> >
> >> Regards,
> >>
> >> Vincent
> >> Le 4 mars 08, ? 22:54, Pavlin Radoslavov a ?crit :
> >>
> >>> expo01 at free.fr wrote:
> >>>
> >>>> We are using Rip and Ripng from Xorp, and we have a problem with a
> >>>> Juniper
> >>>> router that accepts our Rip messages, but rejects the Ripng 
> >>>> messages,
> >>>> pretexting
> >>>> their "ttl is 1, which is different from 255". We use Xorp 1.5-WIP. 
> >>>> I
> >>>> had a very
> >>>> quick look at Xorp sources, and in the rip/tools directory, I found
> >>>> that
> >>>> ripng_announcer makes a call to comm_set_ttl(fd, 255), which seems
> >>>> ok. But in
> >>>> fact, that's true that our Ripng packets are finally issued with a
> >>>> ttl value
> >>>> equal to 1. Any idea ?
> >>>
> >>> I think it is a bug in XORP.
> >>> Plese try the following patch, and if it works I will commit it to
> >>> CVS.
> >>>
> >>> Thanks,
> >>> Pavlin
> >>>
> >>> Index: xrl_port_io.cc
> >>> ===================================================================
> >>> RCS file: /usr/local/www/data/cvs/xorp/rip/xrl_port_io.cc,v
> >>> retrieving revision 1.27
> >>> diff -u -p -r1.27 xrl_port_io.cc
> >>> --- xrl_port_io.cc	4 Jan 2008 03:17:34 -0000	1.27
> >>> +++ xrl_port_io.cc	4 Mar 2008 21:50:41 -0000
> >>> @@ -88,12 +88,12 @@ XrlPortIO<IPv4>::request_open_bind_socke
> >>>
> >>>  template <>
> >>>  bool
> >>> -XrlPortIO<IPv4>::request_ttl_one()
> >>> +XrlPortIO<IPv4>::request_ttl()
> >>>  {
> >>>      XrlSocket4V0p1Client cl(&_xr);
> >>>      return cl.send_set_socket_option(
> >>> -		_ss.c_str(), socket_id(), "multicast_ttl", 1,
> >>> -		callback(this, &XrlPortIO<IPv4>::ttl_one_cb));
> >>> +		_ss.c_str(), socket_id(), "multicast_ttl", RIP_TTL,
> >>> +		callback(this, &XrlPortIO<IPv4>::ttl_cb));
> >>>  }
> >>>
> >>>  template <>
> >>> @@ -191,12 +191,12 @@ XrlPortIO<IPv6>::request_open_bind_socke
> >>>
> >>>  template <>
> >>>  bool
> >>> -XrlPortIO<IPv6>::request_ttl_one()
> >>> +XrlPortIO<IPv6>::request_ttl()
> >>>  {
> >>>      XrlSocket6V0p1Client cl(&_xr);
> >>>      return cl.send_set_socket_option(
> >>> -		_ss.c_str(), socket_id(), "multicast_ttl", 1,
> >>> -		callback(this, &XrlPortIO<IPv6>::ttl_one_cb));
> >>> +		_ss.c_str(), socket_id(), "multicast_ttl", RIP_NG_HOP_COUNT,
> >>> +		callback(this, &XrlPortIO<IPv6>::ttl_cb));
> >>>  }
> >>>
> >>>  template <>
> >>> @@ -343,8 +343,8 @@ XrlPortIO<A>::startup_socket()
> >>>  	// If we succeed here the path is:
> >>>  	// request_open_bind_socket()
> >>>  	// -> open_bind_socket_cb()
> >>> -	//    -> request_ttl_one()
> >>> -	//	 -> ttl_one_cb()
> >>> +	//    -> request_ttl()
> >>> +	//	 -> ttl_cb()
> >>>  	//	     -> request_no_loop()
> >>>  	//		-> no_loop_cb()
> >>>  	//		   ->request_socket_join()
> >>> @@ -379,17 +379,17 @@ XrlPortIO<A>::open_bind_socket_cb(const
> >>>      _sid = *psid;
> >>>      socket_manager.add_sockid(_ss, _sid);
> >>>
> >>> -    if (request_ttl_one() == false) {
> >>> -	set_status(SERVICE_FAILED, "Failed requesting ttl/hops of 1.");
> >>> +    if (request_ttl() == false) {
> >>> +	set_status(SERVICE_FAILED, "Failed requesting ttl/hops.");
> >>>      }
> >>>  }
> >>>
> >>>  template <typename A>
> >>>  void
> >>> -XrlPortIO<A>::ttl_one_cb(const XrlError& e)
> >>> +XrlPortIO<A>::ttl_cb(const XrlError& e)
> >>>  {
> >>>      if (e != XrlError::OKAY()) {
> >>> -	XLOG_WARNING("Failed to set ttl/hops to 1");
> >>> +	XLOG_WARNING("Failed to set ttl/hops.");
> >>>      }
> >>>      if (request_no_loop() == false) {
> >>>  	set_status(SERVICE_FAILED,
> >>> Index: xrl_port_io.hh
> >>> ===================================================================
> >>> RCS file: /usr/local/www/data/cvs/xorp/rip/xrl_port_io.hh,v
> >>> retrieving revision 1.13
> >>> diff -u -p -r1.13 xrl_port_io.hh
> >>> --- xrl_port_io.hh	4 Jan 2008 03:17:34 -0000	1.13
> >>> +++ xrl_port_io.hh	4 Mar 2008 21:50:41 -0000
> >>> @@ -94,8 +94,8 @@ private:
> >>>      bool request_open_bind_socket();
> >>>      void open_bind_socket_cb(const XrlError& xe, const string* 
> >>> psid);
> >>>
> >>> -    bool request_ttl_one();
> >>> -    void ttl_one_cb(const XrlError& xe);
> >>> +    bool request_ttl();
> >>> +    void ttl_cb(const XrlError& xe);
> >>>
> >>>      bool request_no_loop();
> >>>      void no_loop_cb(const XrlError& xe);
> >>
> >>
> >> _______________________________________________
> >> Xorp-users mailing list
> >> Xorp-users at xorp.org
> >> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users
> >
> 
> 
> _______________________________________________
> Xorp-users mailing list
> Xorp-users at xorp.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users


From yueli.m at gmail.com  Fri Mar  7 09:38:42 2008
From: yueli.m at gmail.com (Yue Li)
Date: Fri, 7 Mar 2008 12:38:42 -0500
Subject: [Xorp-users] OSPF terminated with signal 6.
Message-ID: <49567c360803070938v375eb5a9oc4df656f76fb0835@mail.gmail.com>

Hi, All

The ospfv2 module is terminated with signal 6.
I got the following error msg:
[ 2008/03/07 11:55:06  FATAL xorp_ospfv2:3279 OSPF +2964
area_router.cc get_entry_database ] Index too far 72 length 72

I have several xorp instances running, they have similar config files,
but only one is terminated abnormally (above), others run well.

Could anyone give some clues?

Thanks a lot!


From greearb at candelatech.com  Fri Mar  7 10:05:11 2008
From: greearb at candelatech.com (Ben Greear)
Date: Fri, 07 Mar 2008 10:05:11 -0800
Subject: [Xorp-users] OSPF terminated with signal 6.
In-Reply-To: <49567c360803070938v375eb5a9oc4df656f76fb0835@mail.gmail.com>
References: <49567c360803070938v375eb5a9oc4df656f76fb0835@mail.gmail.com>
Message-ID: <47D183D7.3070405@candelatech.com>

Yue Li wrote:
> Hi, All
> 
> The ospfv2 module is terminated with signal 6.
> I got the following error msg:
> [ 2008/03/07 11:55:06  FATAL xorp_ospfv2:3279 OSPF +2964
> area_router.cc get_entry_database ] Index too far 72 length 72
> 
> I have several xorp instances running, they have similar config files,
> but only one is terminated abnormally (above), others run well.
> 
> Could anyone give some clues?

At the least, tell us what version of Xorp you are running.

Ben

-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


From dscher at mitre.org  Sun Mar  9 15:02:35 2008
From: dscher at mitre.org (Scher, Dave)
Date: Sun, 9 Mar 2008 18:02:35 -0400
Subject: [Xorp-users] Simple Question
Message-ID: <9472CDDE9370AF4C871D40FD2ADB92BC02698511@IMCSRV1.MITRE.ORG>

In the XORP User Manual on page 96 you can find the following excerpt
about a BGP router originating two subnets.  
My question is what configuration command invokes originating route
advertisements for BGP.  Seems to me that you have to either import
static routes to advertise.
Or more simply that BGP will advertise directly connected nets over
BGP.  
 
What is the XORP equivalent of the cisco commands:
 
BGP Router 65000
neighbor 192.168.1.100 remote-as 65001
network 10.10.10.0 mask 255.255.255.0
 
Thanks.
Dave
 
This router is also configured to originate routing advertisements for
two subnets. These subnets might be

directly connected, or might be reachable via IGP routing.

The first advertisement this router originates is for subnet
128.16.16/24, reachable via both unicast and

multicast. The nexthop specified in 128.16.64.1, and this must be
reachable via other routes in the routing

table, or this advertisement will not be made. If this router had any
IBGP peerings, then the BGP route

advertised to those peers would indicate that 128.16.16/24 was
reachable via next hop 128.16.64.1. However

in this case the only peering is an EBGP peering, and the next hop in
all routes sent to that peer is set to

128.16.64.4 according to the nexthop directive for the peering.

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20080309/332dd7b6/attachment.html 

From jclark at metricsystems.com  Sun Mar  9 21:54:51 2008
From: jclark at metricsystems.com (John Clark)
Date: Sun, 09 Mar 2008 20:54:51 -0800
Subject: [Xorp-users] Dropping packet from foreign network message???
Message-ID: <47D4BF1B.8090407@metricsystems.com>

I'm just setting up xorp to do OSPF and BGP routing protocols. Since I 
don't have an intimate knowledge
of the XORP configuration setup, I seem to be getting the above message 
on the machines that I've configured
for a single area ospf network.

Four machines are connected via 3 point-to-point links, and each of the 
machines have an ethernet connection to
their 'local' ethernet network.

The foreign packet dropped message appears to be a packet from point to 
point link partners.


Thanks for any assistence,

John Clark.



A schematic:
---------------------------------------------

                             CPU 1 -----------(192.168.2.2)
                                 |
                                 |
                         (10.10.0.2)
                                 |
                                 |
                         (10.10.0.1)
                                 |
                                 |

(192.168.4.2) ----- CPU 2 ----- (10.11.0.1)   <---------> (10.11.0.2) 
----- CPU 3 ----- (192.168.6.2)
                                  |
                                  |
                          (10.12.0.1)
                                  |
                                  |
                         (10.12.0.2)
                                  |
                             CPU 4 ----------- (192.168.8.2)


--------------------------------------

So on any given CPU I see this message for the arm of the p-to-p links 
indicating a foreign packet has been received and dropped.

For example, CPU 4 reports dropped packets for foreign network entity 
10.10.0.1, and similarly on CPU 3
reporting foreign packets from 10.11.0.1

And CPU 2 reports all xx.xx.xx.2 packet dropped.

Here is the config for CPU 2 and one of the others.
--------------------------------------------------------------------------------------------------------
/* $XORP: xorp/rtrmgr/config/interfaces.boot,v 1.1 2007/08/30 06:32:17 
pavlin Exp $ */

interfaces {
    interface eth5 {
    default-system-config
    }
    interface wp1chdl {
    /* Use the default setup as configured in the system */
    default-system-config
    }
    interface wp2chdl {
    /* Use the default setup as configured in the system */
    default-system-config
    }
    interface wp3chdl {
    /* Use the default setup as configured in the system */
    default-system-config
    }
}

protocols {
    ospf4 {
        router-id: 10.10.0.1
        area 0.0.0.51 {
            interface eth5 {
                vif eth5 {
                    address 192.168.4.2 {
                    disable: false
                    }
                }
            }
            interface wp1chdl {
                vif wp1chdl {
                    address 10.10.0.1 {
                    disable: false
                    }
                }
            }
            interface wp2chdl {
                vif wp2chdl {
                    address 10.11.0.1 {
                    disable: false
                    }
                }
            }
            interface wp3chdl {
                vif wp3chdl {
                    address 10.12.0.1 {
                    disable: false
                    }
                }
            }
        }
    }
}
--------------------------------------------------------------------

Here is the config.boot for CPU 3

--------------------------------------------------------------------
/* $XORP: xorp/rtrmgr/config/interfaces.boot,v 1.1 2007/08/30 06:32:17 
pavlin Exp $ */

interfaces {
    interface eth5 {
    default-system-config
    }
    interface wp1chdl {
    /* Use the default setup as configured in the system */
    default-system-config
    }
}

protocols {
    ospf4 {
        router-id 10.11.0.2
        area 0.0.0.51 {
            interface eth5 {
                vif eth5 {
                    address 192.168.6.2 {
                    disable: false
                    }
                }
            }
            interface wp1chdl {
                vif wp1chdl {
                    address 10.11.0.2 {
                    disable: false
                    }
                }
            }
        }
    }
}




From andreas.voellmy at gmail.com  Mon Mar 10 12:09:15 2008
From: andreas.voellmy at gmail.com (Andreas Voellmy)
Date: Mon, 10 Mar 2008 15:09:15 -0400
Subject: [Xorp-users] Fwd: from and to blocks of policy terms
In-Reply-To: <200802120535.m1C5ZMFI014730@fruitcake.ICSI.Berkeley.EDU>
References: <6d3800770802061125h32c4f259s94107f31cbc623d9@mail.gmail.com>
	<6d3800770802101603j4834facal43c3fd948ad3a321@mail.gmail.com>
	<200802111919.m1BJJUZY007068@fruitcake.ICSI.Berkeley.EDU>
	<6d3800770802111309j79b003e9m7c1921a20ee5bafc@mail.gmail.com>
	<200802120535.m1C5ZMFI014730@fruitcake.ICSI.Berkeley.EDU>
Message-ID: <6d3800770803101209o7906df81ic806d89a6da08962@mail.gmail.com>

A while back I asked a few questions about the semantics of BGP
policies in Xorp. I now have a 3 computer Xorp setup so I can actually
try these policies. I've just gotten started with my experiments, but
already I've found cases which don't seem to match either the xorp
manual or what I've heard on this list. It's also possible that I've
misunderstood something. I'd really appreciate some help understanding
these policies.

I have a setup with three computers, called A, B, and C, running xorp
bgp sessions between each pair (AB,AC,BC). C redistributes a static
route to A, but not to B. There are no other routes being advertised
or redistributed in the system.

When I configure A with this import policy "from {neighbor: [C's
address]} then {reject}", I would expect that A will not enter any
route learned from C into its bgp table. However, when I run a "show
bgp routes" command , the route from C shows up. It is marked as valid
("*") but not as being the best (">"). The manual says that a route is
valid when the nexthop is reachable and when the route is not filtered
by inbound filters. According to this, I'd expect the route to be
considered invalid and for no "*" to show up. Otherwise, if it is
valid, why is it not the best route (since it is the only route in A's
table). I have tracing on in my import filter and the trace output
shows the result of the term, filter & whole filter to be "reject".
I've pasted my actual configurations below in case that is useful to
anyone.

As a second experiment I configured A with the export policy "from
{protocol: "bgp"; neighbor: [C's address]} then {reject}". I would
expect that this would have no effect on import policy, but would
prevent any routes learned from C to be advertised to any peers. The
behavior of the router is ALMOST consistent with this, but is actually
quite odd. When A starts up, it sends a route advertisement for the
route learned from C to B. B momentarily installs the route. Then A
sends B an update message to withdraw the route, so B removes it from
its table. I find this really odd. Why does A send the route to B at
all?

Thanks for your help. The configurations are pasted below.

--Andreas


/*
This is Computer A

Computer A is 192.168.0.1
Computer B is 192.168.0.3
Computer C is 192.168.0.2
*/


interfaces {
    restore-original-config-on-shutdown: false
    interface "eth0" {
    description: "data interface"
    disable: false
    vif "eth0" {
        disable: false
        address 192.168.0.1 {
        prefix-length: 16
        broadcast: 192.168.255.255
        disable: false
        }
    }
    }
}

fea {
    unicast-forwarding4 {
    disable: false
    forwarding-entries {
        retain-on-startup: false
        retain-on-shutdown:    false
    }
    }
}

protocols {
    bgp {
        bgp-id: 192.168.0.1
        local-as: 45678

        peer 192.168.0.2 {
            local-ip: 192.168.0.1
            as: 34567
            next-hop: 192.168.0.1
        }

        peer 192.168.0.3 {
            local-ip: 192.168.0.1
            as: 23456
            next-hop: 192.168.0.1
        }


        /* import: "imppol" */
        export: "exppol"

    }
}

policy {

    policy-statement imppol {
        term impterm {
            from {
                neighbor: 192.168.0.2
            }
            then {
                trace: 4
                reject
            }
        }
    }

    policy-statement exppol {
        term expterm {
            from {
                protocol: "bgp"
                neighbor: 192.168.0.2
            }
            then {
                trace: 4
                reject
            }
        }
    }
}

/*

This is Computer C

Computer A is 192.168.0.1
Computer B is 192.168.0.3
Computer C is 192.168.0.2
*/

interfaces {
    restore-original-config-on-shutdown: false
    interface "eth0" {
	description: "data interface"
	disable: false
	vif "eth0" {
	    disable: false
	    address 192.168.0.2 {
		prefix-length: 16
		broadcast: 192.168.255.255
		disable: false
	    }
	}
    }
}

fea {
    unicast-forwarding4 {
	disable: false
	forwarding-entries {
	    retain-on-startup: false
	    retain-on-shutdown:	false
	}
    }
}

protocols {
	static {
		route 10.10.11.0/24 {
			next-hop: 192.168.0.2
		}
	}
}

protocols {
	bgp {
		bgp-id: 192.168.0.2
		local-as: 34567

		peer 192.168.0.1 {
			local-ip: 192.168.0.2
			as: 45678
			next-hop: 192.168.0.2
		}
		peer 192.168.0.3 {
			local-ip: 192.168.0.2
			as: 23456
			next-hop: 192.168.0.2
		}
		export: "exppol"
	}
}

policy {
	policy-statement exppol {
		term exppolterm1 {
			from {
				protocol: "static"
			}
			to {
				neighbor: 192.168.0.1
			}
			then {
				accept
			}
		}
		term exppolterm2 {
			from {
				protocol: "static"
			}
			then {
				reject
			}
		}
	}
}

/*

This is Computer B

Computer A is 192.168.0.1
Computer B is 192.168.0.3
Computer C is 192.168.0.2
*/

interfaces {
    restore-original-config-on-shutdown: false
    interface "eth0" {
	description: "data interface"
	disable: false
	vif "eth0" {
	    disable: false
	    address 192.168.0.3 {
		prefix-length: 16
		broadcast: 192.168.255.255
		disable: false
	    }
	}
    }
}

fea {
    unicast-forwarding4 {
	disable: false
	forwarding-entries {
	    retain-on-startup: false
	    retain-on-shutdown:	false
	}
    }
}

protocols {
	static {
		route 10.10.12.0/24 {
			next-hop: 192.168.0.3
		}
	}
}

protocols {
	bgp {
		bgp-id: 192.168.0.3
		local-as: 23456

		peer 192.168.0.1 {
			local-ip: 192.168.0.3
			as: 45678
			next-hop: 192.168.0.3
		}
		peer 192.168.0.2 {
			local-ip: 192.168.0.3
			as: 34567
			next-hop: 192.168.0.3
		}
		import: "imppol"
	}
}

policy {
	policy-statement imppol {
		term imppolterm {
			then {
				trace: 4
				accept
			}
		}
	}
}


From andreas.voellmy at gmail.com  Mon Mar 10 12:34:52 2008
From: andreas.voellmy at gmail.com (Andreas Voellmy)
Date: Mon, 10 Mar 2008 15:34:52 -0400
Subject: [Xorp-users] Fwd: from and to blocks of policy terms
In-Reply-To: <200802120535.m1C5ZMFI014730@fruitcake.ICSI.Berkeley.EDU>
References: <6d3800770802061125h32c4f259s94107f31cbc623d9@mail.gmail.com>
	<6d3800770802101603j4834facal43c3fd948ad3a321@mail.gmail.com>
	<200802111919.m1BJJUZY007068@fruitcake.ICSI.Berkeley.EDU>
	<6d3800770802111309j79b003e9m7c1921a20ee5bafc@mail.gmail.com>
	<200802120535.m1C5ZMFI014730@fruitcake.ICSI.Berkeley.EDU>
Message-ID: <6d3800770803101234j73bcd3bah24e743c0970db2e2@mail.gmail.com>

On Tue, Feb 12, 2008 at 1:35 AM, Pavlin Radoslavov
<pavlin at icsi.berkeley.edu> wrote:
>  > > For example, "from {} to {neighbor: 192.168.1.2} then {accept}"
>  > > can't be used as an export policy, but can be used as an import
>  > > policy. As an import policy, when the routes reach the outbound
>  > > evaluation, only the routes to neighbor 192.168.1.2 will be
>  > > accepted (i.e., transmitted).
>  >
>  >
>  > If I understand you correctly, you are saying that if "from {} to {neighbor:
>  > 192.168.1.2} then {accept}" were an IMPORT policy, then it would be
>  > equivalent to the following EXPORT policy "from {protocol: bgp} to
>  > {neighbor: 192.168.1.2} then {accept}"?
>
>  I believe the answer is yes.
>  However, I should also say that it has been a while since I looked
>  into the policy framework details so I could be wrong.

I tried the policy "from {} to {neighbor: X} then {accept}" as an
import policy and it turns out that it is illegal, that is Xorp (1.4)
rejects it and quits.

--Andreas


From pavlin at ICSI.Berkeley.EDU  Mon Mar 10 12:47:24 2008
From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov)
Date: Mon, 10 Mar 2008 12:47:24 -0700
Subject: [Xorp-users] Fwd: from and to blocks of policy terms
In-Reply-To: <6d3800770803101234j73bcd3bah24e743c0970db2e2@mail.gmail.com> 
References: <6d3800770802061125h32c4f259s94107f31cbc623d9@mail.gmail.com>
	<6d3800770802101603j4834facal43c3fd948ad3a321@mail.gmail.com>
	<200802111919.m1BJJUZY007068@fruitcake.ICSI.Berkeley.EDU>
	<6d3800770802111309j79b003e9m7c1921a20ee5bafc@mail.gmail.com>
	<200802120535.m1C5ZMFI014730@fruitcake.ICSI.Berkeley.EDU>
	<6d3800770803101234j73bcd3bah24e743c0970db2e2@mail.gmail.com>
Message-ID: <200803101947.m2AJlOwo003439@fruitcake.ICSI.Berkeley.EDU>

> >  > > For example, "from {} to {neighbor: 192.168.1.2} then {accept}"
> >  > > can't be used as an export policy, but can be used as an import
> >  > > policy. As an import policy, when the routes reach the outbound
> >  > > evaluation, only the routes to neighbor 192.168.1.2 will be
> >  > > accepted (i.e., transmitted).
> >  >
> >  >
> >  > If I understand you correctly, you are saying that if "from {} to {neighbor:
> >  > 192.168.1.2} then {accept}" were an IMPORT policy, then it would be
> >  > equivalent to the following EXPORT policy "from {protocol: bgp} to
> >  > {neighbor: 192.168.1.2} then {accept}"?
> >
> >  I believe the answer is yes.
> >  However, I should also say that it has been a while since I looked
> >  into the policy framework details so I could be wrong.
> 
> I tried the policy "from {} to {neighbor: X} then {accept}" as an
> import policy and it turns out that it is illegal, that is Xorp (1.4)
> rejects it and quits.

I am slowly starting to remember things...
Please try "from {neighbor: X} then {accept}" as an import policy.
The "to {}" block should apply to the outgoing branch of the control
path (inside BGP), and this information is not available when the
import policy is applied.

Pavlin


From andreas.voellmy at gmail.com  Mon Mar 10 14:45:36 2008
From: andreas.voellmy at gmail.com (Andreas Voellmy)
Date: Mon, 10 Mar 2008 17:45:36 -0400
Subject: [Xorp-users] Fwd: from and to blocks of policy terms
In-Reply-To: <200803101947.m2AJlOwo003439@fruitcake.ICSI.Berkeley.EDU>
References: <6d3800770802061125h32c4f259s94107f31cbc623d9@mail.gmail.com>
	<6d3800770802101603j4834facal43c3fd948ad3a321@mail.gmail.com>
	<200802111919.m1BJJUZY007068@fruitcake.ICSI.Berkeley.EDU>
	<6d3800770802111309j79b003e9m7c1921a20ee5bafc@mail.gmail.com>
	<200802120535.m1C5ZMFI014730@fruitcake.ICSI.Berkeley.EDU>
	<6d3800770803101234j73bcd3bah24e743c0970db2e2@mail.gmail.com>
	<200803101947.m2AJlOwo003439@fruitcake.ICSI.Berkeley.EDU>
Message-ID: <6d3800770803101445q10a3c4e2ke5aa110b7fab8d90@mail.gmail.com>

Yes, the import policy "from {neighbor: X} then {accept}" makes sense.
I am actually glad Xorp does not accept "to {neighbor: X} then
{accept}" as an import policy - I don't know what this policy would
mean.

--Andreas

On Mon, Mar 10, 2008 at 3:47 PM, Pavlin Radoslavov
<pavlin at icsi.berkeley.edu> wrote:
>
> > >  > > For example, "from {} to {neighbor: 192.168.1.2} then {accept}"
>  > >  > > can't be used as an export policy, but can be used as an import
>  > >  > > policy. As an import policy, when the routes reach the outbound
>  > >  > > evaluation, only the routes to neighbor 192.168.1.2 will be
>  > >  > > accepted (i.e., transmitted).
>  > >  >
>  > >  >
>  > >  > If I understand you correctly, you are saying that if "from {} to {neighbor:
>  > >  > 192.168.1.2} then {accept}" were an IMPORT policy, then it would be
>  > >  > equivalent to the following EXPORT policy "from {protocol: bgp} to
>  > >  > {neighbor: 192.168.1.2} then {accept}"?
>  > >
>  > >  I believe the answer is yes.
>  > >  However, I should also say that it has been a while since I looked
>  > >  into the policy framework details so I could be wrong.
>  >
>  > I tried the policy "from {} to {neighbor: X} then {accept}" as an
>  > import policy and it turns out that it is illegal, that is Xorp (1.4)
>  > rejects it and quits.
>
>  I am slowly starting to remember things...
>  Please try "from {neighbor: X} then {accept}" as an import policy.
>  The "to {}" block should apply to the outgoing branch of the control
>  path (inside BGP), and this information is not available when the
>  import policy is applied.
>
>  Pavlin
>


From kellermg at potsdam.edu  Tue Mar 11 08:45:36 2008
From: kellermg at potsdam.edu (Matthew Keller)
Date: 11 Mar 2008 11:45:36 -0400
Subject: [Xorp-users] Related Route Redistribution Ruin
Message-ID: <1205250336.3174.81.camel@mlap>

After 4.5 hours of digging into a problem I'm having, I believe I
finally know enough to ask an intelligent question.

My XORP router is a BGP router peering with another BGP router elsewhere
(not ours). We're receiving thousands of routes, fine, but unable to
send our single route to our BGP peer.

What appears to be happening is that the route I want to send: 

 route 137.143.0.0/16 {
        next-hop: w.x.y.z
 }

is for some reason being ignored because it is related to one of the
connected interfaces (137.143.16.0/20). If I change the route to
ANYTHING not related to a connected interface, ala 137.142.0.0/16 (note
the decrease in the second octet) the route flies out perfectly (albeit
not the route I WANT to send out).

'show route table ipv4 unicast static' is empty if the correct network
is used, and "correct" if the false one is used.

I have used Xorp 1.4, and a CVS checkout from a couple weeks ago.

Am I missing something? How can I force that route to be sent?

-- 
Matthew Keller
Information Security Officer & Network Administrator
Computing & Technology Services
State University of New York @ Potsdam
Potsdam, NY, USA


From pavlin at ICSI.Berkeley.EDU  Tue Mar 11 11:59:50 2008
From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov)
Date: Tue, 11 Mar 2008 11:59:50 -0700
Subject: [Xorp-users] Related Route Redistribution Ruin
In-Reply-To: <1205250336.3174.81.camel@mlap> 
References: <1205250336.3174.81.camel@mlap>
Message-ID: <200803111859.m2BIxoUB004460@fruitcake.ICSI.Berkeley.EDU>

> After 4.5 hours of digging into a problem I'm having, I believe I
> finally know enough to ask an intelligent question.
> 
> My XORP router is a BGP router peering with another BGP router elsewhere
> (not ours). We're receiving thousands of routes, fine, but unable to
> send our single route to our BGP peer.
> 
> What appears to be happening is that the route I want to send: 
> 
>  route 137.143.0.0/16 {
>         next-hop: w.x.y.z
>  }
> 
> is for some reason being ignored because it is related to one of the
> connected interfaces (137.143.16.0/20). If I change the route to
> ANYTHING not related to a connected interface, ala 137.142.0.0/16 (note
> the decrease in the second octet) the route flies out perfectly (albeit
> not the route I WANT to send out).
> 
> 'show route table ipv4 unicast static' is empty if the correct network
> is used, and "correct" if the false one is used.
> 
> I have used Xorp 1.4, and a CVS checkout from a couple weeks ago.
> 
> Am I missing something? How can I force that route to be sent?

For the static route configuration itself lets say you have
configuration like the following:

interfaces {
    interface dc0 {
        vif dc0 {
            address 10.10.10.10 {
                prefix-length: 24
            }
        }
    }
}

fea {
    unicast-forwarding4 {
        disable: false
    }
}

protocols {
    static {
        route 10.10.10.0/24 {
            next-hop: 10.10.10.10
        }
    }
}

With such setup the "show route table ipv4 unicast static" command
should return the route:

user at hostname> show route table ipv4 unicast static 
10.10.10.0/24   [static(1)/1]
                > to 10.10.10.10 via dc0/dc0

[It is odd that in your setup the route is not shown, though I
should note that in my test I am using the latest code from CVS. One
reason that comes to mind to prevent it from showing is if the cable
for the interface toward the next-hop for the route is disconnected.]

However, the same route is added to RIB by the "connected"
component:

user at hostname> show route table ipv4 unicast connected
10.10.10.0/24   [connected(0)/0]
                > via dc0/dc0

The admin distance for connected routes is better than the
static routes, therefore the winner will be the connected route:

user at hostname> show route table ipv4 unicast final 
10.10.10.0/24   [connected(0)/0]
                > via dc0/dc0


Below I assume that in your configuration you export the "connected"
routes only.

When you export routes into BGP (or into any other protocol), only
the winning routes (at the "final" table) from the exported protocol
are actually exported. Therefore in the above example the
10.10.10.0/24 route from "static" loses to the same route from
"connected" and it will not be exported into BGP.

If you really want to export a particular route into BGP that
happens to be one of your directly connected subnets, then you need
to do something like the following:

policy {
    policy-statement export-connected-subnet {
        term 100 {
            from {
                protocol: "connected"
                network4: 10.10.10.0/24
            }
        }
    }
}

protocols {
    bgp {
        export: "export-connected-subnet"
        ...
    }
}

Hope that helps,
Pavlin


From atanu at ICSI.Berkeley.EDU  Tue Mar 11 13:54:37 2008
From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh)
Date: Tue, 11 Mar 2008 13:54:37 -0700
Subject: [Xorp-users] OSPF terminated with signal 6.
In-Reply-To: Message from "Yue Li" <yueli.m@gmail.com> of "Fri,
	07 Mar 2008 12:38:42 EST."
	<49567c360803070938v375eb5a9oc4df656f76fb0835@mail.gmail.com> 
Message-ID: <52460.1205268877@tigger.icir.org>

Hi,

You found a bug which is now fixed in CVS:
<http://mailman.icsi.berkeley.edu/pipermail/xorp-cvs/2008-March/010790.html>

I think that during the database exchange the last LSA in the database
was invalidated, an attempt was then made to get the next LSA when no
more were present.

	Atanu.

>>>>> "Yue" == Yue Li <yueli.m at gmail.com> writes:

    Yue> Hi, All The ospfv2 module is terminated with signal 6.  I got
    Yue> the following error msg: [ 2008/03/07 11:55:06 FATAL
    Yue> xorp_ospfv2:3279 OSPF +2964 area_router.cc get_entry_database ]
    Yue> Index too far 72 length 72

    Yue> I have several xorp instances running, they have similar config
    Yue> files, but only one is terminated abnormally (above), others
    Yue> run well.

    Yue> Could anyone give some clues?

    Yue> Thanks a lot!

    Yue> _______________________________________________ Xorp-users
    Yue> mailing list Xorp-users at xorp.org
    Yue> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users


From msrinivas at ceeyes.com  Wed Mar 12 22:08:40 2008
From: msrinivas at ceeyes.com (Srinivasa Rao)
Date: Thu, 13 Mar 2008 10:38:40 +0530
Subject: [Xorp-users] hardware calls
Message-ID: <000601c884c8$4e515da0$2083a8c0@ceeyes.com>

hi all,
Are there any hardware related calls in xorp?
please let me know.

Thanks & Regards
msrao
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20080313/c05ce063/attachment.html 

From Samuel.DeHoyos at NGC.com  Thu Mar 13 08:22:37 2008
From: Samuel.DeHoyos at NGC.com (De Hoyos, Samuel)
Date: Thu, 13 Mar 2008 10:22:37 -0500
Subject: [Xorp-users] IGMP Proxy
In-Reply-To: <200803111859.m2BIxoUB004460@fruitcake.ICSI.Berkeley.EDU>
References: <1205250336.3174.81.camel@mlap>
	<200803111859.m2BIxoUB004460@fruitcake.ICSI.Berkeley.EDU>
Message-ID: <F45D63E8C730D04F899B1227D5D03FD801126BEC@XMBIL101.northgrum.com>

I would like to know if there is a way to configure the XORP software to
behave like an IGMP proxy.

We have a system in the lab that will become operational and needs to
pass along IGMP Reports from the LAN side (eth0) to the WAN side (eth1)
of the LINUX XORP server. The device on the WAN side does not support
any Multicast Routing protocols other then IGMP and that will not
change. However, the WAN side device will be receiving/sending Multicast
Streams and will forward the traffic to the LINUX XORP Server to be
passed along to the LAN side to the MCAST Source/Receiver. Below is a
diagram of our setup

Mcast_source/receiver-----------LinuxXORP-------WAN_Side_Device
         		             ^        ^       
          		             |        |       
       			      eth0	   eth1     
           		
If someone has configured an IGMP proxy using XORP or other software
your assistance will be greatly appreciated. Please note that we do not
have the option of switching hardware platforms or modifying the
software on the WAN side device.  

If its not possible, I would also like to know that as well.

Thanks,
Sam De Hoyos


From pavlin at ICSI.Berkeley.EDU  Thu Mar 13 13:18:50 2008
From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov)
Date: Thu, 13 Mar 2008 13:18:50 -0700
Subject: [Xorp-users] IGMP Proxy
In-Reply-To: <F45D63E8C730D04F899B1227D5D03FD801126BEC@XMBIL101.northgrum.com>
References: <1205250336.3174.81.camel@mlap>
	<200803111859.m2BIxoUB004460@fruitcake.ICSI.Berkeley.EDU>
	<F45D63E8C730D04F899B1227D5D03FD801126BEC@XMBIL101.northgrum.com>
Message-ID: <200803132018.m2DKIoNQ008753@fruitcake.ICSI.Berkeley.EDU>

De Hoyos, Samuel <Samuel.DeHoyos at NGC.com> wrote:

> I would like to know if there is a way to configure the XORP software to
> behave like an IGMP proxy.

I am afraid the answer is no.
IGMP proxy implementation for XORP is on our TODO list, but
currently you can use XORP for multicast routing purpose only if you
run PIM-SM (which from your description doesn't seem to be an
option).

Quick search reveals the following open-source IGMP proxy
implementations:

http://sourceforge.net/projects/igmpproxy
http://potiron.loria.fr/projects/madynes/internals/perso/lahmadi/igmpv3proxy

However I should note that I haven't tried to use them.
Also, I don't know whether they are based on the IGMP Proxy spec
(RFC 4605).

Regards,
Pavlin

> We have a system in the lab that will become operational and needs to
> pass along IGMP Reports from the LAN side (eth0) to the WAN side (eth1)
> of the LINUX XORP server. The device on the WAN side does not support
> any Multicast Routing protocols other then IGMP and that will not
> change. However, the WAN side device will be receiving/sending Multicast
> Streams and will forward the traffic to the LINUX XORP Server to be
> passed along to the LAN side to the MCAST Source/Receiver. Below is a
> diagram of our setup
> 
> Mcast_source/receiver-----------LinuxXORP-------WAN_Side_Device
>          		             ^        ^       
>           		             |        |       
>        			      eth0	   eth1     
>            		
> If someone has configured an IGMP proxy using XORP or other software
> your assistance will be greatly appreciated. Please note that we do not
> have the option of switching hardware platforms or modifying the
> software on the WAN side device.  
> 
> If its not possible, I would also like to know that as well.
> 
> Thanks,
> Sam De Hoyos
> 
> _______________________________________________
> Xorp-users mailing list
> Xorp-users at xorp.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users


From atanu at ICSI.Berkeley.EDU  Thu Mar 13 14:14:55 2008
From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh)
Date: Thu, 13 Mar 2008 14:14:55 -0700
Subject: [Xorp-users] Simple Question
In-Reply-To: Message from "Scher, Dave" <dscher@mitre.org> of "Sun,
	09 Mar 2008 18:02:35 EDT."
	<9472CDDE9370AF4C871D40FD2ADB92BC02698511@IMCSRV1.MITRE.ORG> 
Message-ID: <9758.1205442895@tigger.icir.org>

An embedded and charset-unspecified text was scrubbed...
Name: bgp.munch1.1.boot
Url: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20080313/9dbf445b/attachment.ksh 

From david.bond at themis.com  Sat Mar 15 01:53:28 2008
From: david.bond at themis.com (David Bond)
Date: Sat, 15 Mar 2008 01:53:28 -0700 (PDT)
Subject: [Xorp-users] Bonded Interfaces
Message-ID: <31613886.413651205571208662.JavaMail.root@mail.themis.com>

Does anyone have experience using bonded interfaces with xorp? And if so, do you need to define a vif for each logical interface that is part of the bond? Or can you define only those logical interfaces that you want xorp to control?

David

-- 
*********************************************************************
David Bond
Themis Computer
47200 Bayside Parkway
Fremont, CA 94538

Telephone: +1-510-252-0870
Fax: +1-510-490-5529
*********************************************************************
                              No matter where you go, there you are
                                                                            - B. Banzai
*********************************************************************


From dirk.schulz at kinzesberg.de  Sat Mar 15 05:21:11 2008
From: dirk.schulz at kinzesberg.de (Dirk H. Schulz)
Date: Sat, 15 Mar 2008 13:21:11 +0100
Subject: [Xorp-users] Bonded Interfaces
In-Reply-To: <31613886.413651205571208662.JavaMail.root@mail.themis.com>
References: <31613886.413651205571208662.JavaMail.root@mail.themis.com>
Message-ID: <68251F0E66B2139A0CF4A127@Dirks-MacBook-Pro.local>

Hi David,

we are using bonded interfaces with CentOS/RedHat. We have defined the 
bonding master and its slave at the operating system level and configured 
only the bonding master (that is the bonding interface) within xorp config 
like so:

>     interface bond0 {
> 		description: "area1 bonding interface"
> 		disable: false
> 		vif bond0 {
> 			disable: false
> 			address 1.2.3.4 {
> 				prefix-lenght: 26
> 				broadcast: 1.2.3.5
> 				disable: false
> 			}
> 		}

Dirk


--On 15. M?rz 2008 01:53:28 -0700 David Bond <david.bond at themis.com> wrote:

> Does anyone have experience using bonded interfaces with xorp? And if so,
> do you need to define a vif for each logical interface that is part of
> the bond? Or can you define only those logical interfaces that you want
> xorp to control?
>
> David
>
> --
> *********************************************************************
> David Bond
> Themis Computer
> 47200 Bayside Parkway
> Fremont, CA 94538
>
> Telephone: +1-510-252-0870
> Fax: +1-510-490-5529
> *********************************************************************
>                               No matter where you go, there you are
>
> - B. Banzai
> *********************************************************************
>
> _______________________________________________
> Xorp-users mailing list
> Xorp-users at xorp.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users



--------------------------------------------------------------
Dirk H. Schulz
IT Systems Service
Wiesenweg 12, 85567 Grafing
Tel. 0 80 92/86 25 68
Fax. 0 80 92/86 25 72
--------------------------------------------------------------
Technik vom Feinsten - und das n?tige Tuning


From david.bond at themis.com  Sat Mar 15 05:47:35 2008
From: david.bond at themis.com (David Bond)
Date: Sat, 15 Mar 2008 05:47:35 -0700 (PDT)
Subject: [Xorp-users] Bonded Interfaces
In-Reply-To: <68251F0E66B2139A0CF4A127@Dirks-MacBook-Pro.local>
Message-ID: <28150027.413681205585255058.JavaMail.root@mail.themis.com>

Dirk,

The situation is further complicated since there are pseudo interfaces created on the bonded interface, such as bond0:1, bond0:2, etc. Also, there is a requirement to forward traffic from a specific ip address to a different ip address using one of these pseudo interfaces. Currently Iptables is being used to perform this function, but I think there is a conflict due to some of the messages that I'm seeing from xorp_rtrmgr. The error message in particular is "No Finder?".

David
----- Original Message -----
From: "Dirk H. Schulz" <dirk.schulz at kinzesberg.de>
To: "David Bond" <david.bond at themis.com>, xorp-users at xorp.org
Sent: Saturday, March 15, 2008 5:21:11 AM (GMT-0800) America/Los_Angeles
Subject: Re: [Xorp-users] Bonded Interfaces

Hi David,

we are using bonded interfaces with CentOS/RedHat. We have defined the 
bonding master and its slave at the operating system level and configured 
only the bonding master (that is the bonding interface) within xorp config 
like so:

>     interface bond0 {
> 		description: "area1 bonding interface"
> 		disable: false
> 		vif bond0 {
> 			disable: false
> 			address 1.2.3.4 {
> 				prefix-lenght: 26
> 				broadcast: 1.2.3.5
> 				disable: false
> 			}
> 		}

Dirk


--On 15. M?rz 2008 01:53:28 -0700 David Bond <david.bond at themis.com> wrote:

> Does anyone have experience using bonded interfaces with xorp? And if so,
> do you need to define a vif for each logical interface that is part of
> the bond? Or can you define only those logical interfaces that you want
> xorp to control?
>
> David
>
> --
> *********************************************************************
> David Bond
> Themis Computer
> 47200 Bayside Parkway
> Fremont, CA 94538
>
> Telephone: +1-510-252-0870
> Fax: +1-510-490-5529
> *********************************************************************
>                               No matter where you go, there you are
>
> - B. Banzai
> *********************************************************************
>
> _______________________________________________
> Xorp-users mailing list
> Xorp-users at xorp.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users



--------------------------------------------------------------
Dirk H. Schulz
IT Systems Service
Wiesenweg 12, 85567 Grafing
Tel. 0 80 92/86 25 68
Fax. 0 80 92/86 25 72
--------------------------------------------------------------
Technik vom Feinsten - und das n?tige Tuning


-- 
*********************************************************************
David Bond
Themis Computer
47200 Bayside Parkway
Fremont, CA 94538

Telephone: +1-510-252-0870
Fax: +1-510-490-5529
*********************************************************************
                              No matter where you go, there you are
                                                                            - B. Banzai
*********************************************************************



From dirk.schulz at kinzesberg.de  Sun Mar 16 01:09:35 2008
From: dirk.schulz at kinzesberg.de (Dirk H. Schulz)
Date: Sun, 16 Mar 2008 09:09:35 +0100
Subject: [Xorp-users] Bonded Interfaces
In-Reply-To: <28150027.413681205585255058.JavaMail.root@mail.themis.com>
References: <28150027.413681205585255058.JavaMail.root@mail.themis.com>
Message-ID: <8326C96A5785BBAEB82DF232@Dirks-MacBook-Pro.local>

Hi David,

--On 15. M?rz 2008 05:47:35 -0700 David Bond <david.bond at themis.com> wrote:

> Dirk,
>
> The situation is further complicated since there are pseudo interfaces
> created on the bonded interface, such as bond0:1, bond0:2, etc.

That should be no problem, since Xorp abstracts from the interface layer - 
it uses every kind of interface equally.

> Also,
> there is a requirement to forward traffic from a specific ip address to a
> different ip address using one of these pseudo interfaces. Currently
> Iptables is being used to perform this function,

You could use static routes in Xorp to get this working. It would be easier 
to troubleshoot if you do all the routing with one tool.

> but I think there is a
> conflict due to some of the messages that I'm seeing from xorp_rtrmgr.
> The error message in particular is "No Finder?".

I am sorry, but I do not know what this message means.

Dirk
>
> David
> ----- Original Message -----
> From: "Dirk H. Schulz" <dirk.schulz at kinzesberg.de>
> To: "David Bond" <david.bond at themis.com>, xorp-users at xorp.org
> Sent: Saturday, March 15, 2008 5:21:11 AM (GMT-0800) America/Los_Angeles
> Subject: Re: [Xorp-users] Bonded Interfaces
>
> Hi David,
>
> we are using bonded interfaces with CentOS/RedHat. We have defined the
> bonding master and its slave at the operating system level and configured
> only the bonding master (that is the bonding interface) within xorp
> config  like so:
>
>>     interface bond0 {
>> 		description: "area1 bonding interface"
>> 		disable: false
>> 		vif bond0 {
>> 			disable: false
>> 			address 1.2.3.4 {
>> 				prefix-lenght: 26
>> 				broadcast: 1.2.3.5
>> 				disable: false
>> 			}
>> 		}
>
> Dirk
>
>
> --On 15. M?rz 2008 01:53:28 -0700 David Bond <david.bond at themis.com>
> wrote:
>
>> Does anyone have experience using bonded interfaces with xorp? And if so,
>> do you need to define a vif for each logical interface that is part of
>> the bond? Or can you define only those logical interfaces that you want
>> xorp to control?
>>
>> David
>>
>> --
>> *********************************************************************
>> David Bond
>> Themis Computer
>> 47200 Bayside Parkway
>> Fremont, CA 94538
>>
>> Telephone: +1-510-252-0870
>> Fax: +1-510-490-5529
>> *********************************************************************
>>                               No matter where you go, there you are
>>
>> - B. Banzai
>> *********************************************************************
>>
>> _______________________________________________
>> Xorp-users mailing list
>> Xorp-users at xorp.org
>> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users
>
>
>
> --------------------------------------------------------------
> Dirk H. Schulz
> IT Systems Service
> Wiesenweg 12, 85567 Grafing
> Tel. 0 80 92/86 25 68
> Fax. 0 80 92/86 25 72
> --------------------------------------------------------------
> Technik vom Feinsten - und das n?tige Tuning
>
>
> --
> *********************************************************************
> David Bond
> Themis Computer
> 47200 Bayside Parkway
> Fremont, CA 94538
>
> Telephone: +1-510-252-0870
> Fax: +1-510-490-5529
> *********************************************************************
>                               No matter where you go, there you are
>
> - B. Banzai
> *********************************************************************
>
>
> _______________________________________________
> Xorp-users mailing list
> Xorp-users at xorp.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users



--------------------------------------------------------------
Dirk H. Schulz
IT Systems Service
Wiesenweg 12, 85567 Grafing
Tel. 0 80 92/86 25 68
Fax. 0 80 92/86 25 72
--------------------------------------------------------------
Technik vom Feinsten - und das n?tige Tuning


From david.bond at themis.com  Mon Mar 17 02:53:22 2008
From: david.bond at themis.com (David Bond)
Date: Mon, 17 Mar 2008 02:53:22 -0700 (PDT)
Subject: [Xorp-users] Configuration Issue with pseudo interfaces
Message-ID: <22070977.414071205747602944.JavaMail.root@mail.themis.com>

I'm trying to configure xorp to use a number of pseudo interfaces. However, when xorp is started, I get the following error:

bash-2.05b# /usr/local/xorp/bin/xorp_rtrmgr -b /mnt/jffs2/config.boot
[ 1969/12/31 19:48:03  ERROR xorp_rtrmgr:1400 RTRMGR +330 main_rtrmgr.cc run ] rtrmgr shutting down due to an init error: PARSE ERROR [Config File /mnt/jffs2/config.boot, line 18]: syntax error; Last symbol parsed was "bond0"

It appears that xorp does not like the syntax bond0:1 for the pseudo interface. Any suggestions, thoughts, or comments.  I am not committed to using pseudo interfaces, but I do need to have the ability to have 2 physical interfaces that can respond to up to 3 different sub-nets, and a total of 5 different IP addresses.

/* $XORP: xorp/rtrmgr/config.boot.sample,v 1.46 2007/03/12 10:16:05 atanu Exp $
*/


interfaces {
    restore-original-config-on-shutdown: false
    interface bond0 {
        description: "lab network"
        disable: false
        /* default-system-config */
interfaces {
    restore-original-config-on-shutdown: false
    interface bond0 {
        description: "lab network"
        disable: false
        /* default-system-config */
        vif bond0 {
            disable: false
            address 10.250.61.253 {
                prefix-length: 24
                broadcast: 10.250.61.255
                disable: false
            }
          }
==>           vif bond0:1 {
               disable: false
               address 192.168.84.38 {
                        prefix-length: 24
                        broadcast: 192.168.84.255
                        disable: false
            }
          }
        }

Thank you,
David
-- 
*********************************************************************
David Bond
Themis Computer
47200 Bayside Parkway
Fremont, CA 94538

Telephone: +1-510-252-0870
Fax: +1-510-490-5529
*********************************************************************
                              No matter where you go, there you are
                                                                            - B. Banzai
*********************************************************************


From pavlin at ICSI.Berkeley.EDU  Mon Mar 17 09:08:54 2008
From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov)
Date: Mon, 17 Mar 2008 09:08:54 -0700
Subject: [Xorp-users] Configuration Issue with pseudo interfaces
In-Reply-To: <22070977.414071205747602944.JavaMail.root@mail.themis.com> 
References: <22070977.414071205747602944.JavaMail.root@mail.themis.com>
Message-ID: <200803171608.m2HG8sGe013358@fruitcake.ICSI.Berkeley.EDU>

David Bond <david.bond at themis.com> wrote:

> I'm trying to configure xorp to use a number of pseudo interfaces. However, when xorp is started, I get the following error:
> 
> bash-2.05b# /usr/local/xorp/bin/xorp_rtrmgr -b /mnt/jffs2/config.boot
> [ 1969/12/31 19:48:03  ERROR xorp_rtrmgr:1400 RTRMGR +330 main_rtrmgr.cc run ] rtrmgr shutting down due to an init error: PARSE ERROR [Config File /mnt/jffs2/config.boot, line 18]: syntax error; Last symbol parsed was "bond0"
> 
> It appears that xorp does not like the syntax bond0:1 for the pseudo interface. Any suggestions, thoughts, or comments.  I am not committed to using pseudo interfaces, but I do need to have the ability to have 2 physical interfaces that can respond to up to 3 different sub-nets, and a total of 5 different IP addresses.

What is the output of the "ip addr" Linux command?
I guess that the "bond0:1" pseudo interface corresponds to an alias
IP address, so you might try to use "bond0" instead.
If you don't want XORP to use some of the IP alias addresses
configured on bond0, then you should explicitly configure only those
IP addresses you want to use.

Regards,
Pavlin

> /* $XORP: xorp/rtrmgr/config.boot.sample,v 1.46 2007/03/12 10:16:05 atanu Exp $
> */
> 
> 
> interfaces {
>     restore-original-config-on-shutdown: false
>     interface bond0 {
>         description: "lab network"
>         disable: false
>         /* default-system-config */
> interfaces {
>     restore-original-config-on-shutdown: false
>     interface bond0 {
>         description: "lab network"
>         disable: false
>         /* default-system-config */
>         vif bond0 {
>             disable: false
>             address 10.250.61.253 {
>                 prefix-length: 24
>                 broadcast: 10.250.61.255
>                 disable: false
>             }
>           }
> ==>           vif bond0:1 {
>                disable: false
>                address 192.168.84.38 {
>                         prefix-length: 24
>                         broadcast: 192.168.84.255
>                         disable: false
>             }
>           }
>         }
> 
> Thank you,
> David
> -- 
> *********************************************************************
> David Bond
> Themis Computer
> 47200 Bayside Parkway
> Fremont, CA 94538
> 
> Telephone: +1-510-252-0870
> Fax: +1-510-490-5529
> *********************************************************************
>                               No matter where you go, there you are
>                                                                             - B. Banzai
> *********************************************************************
> 
> _______________________________________________
> Xorp-users mailing list
> Xorp-users at xorp.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users


From david.bond at themis.com  Mon Mar 17 09:13:33 2008
From: david.bond at themis.com (David Bond)
Date: Mon, 17 Mar 2008 09:13:33 -0700 (PDT)
Subject: [Xorp-users] Configuration Issue with pseudo interfaces
In-Reply-To: <200803171608.m2HG8sGe013358@fruitcake.ICSI.Berkeley.EDU>
Message-ID: <18830426.415321205770413838.JavaMail.root@mail.themis.com>

By using the default-system-config command, I was able to get xorp up and running. It picks up all of the pseudo interfaces that are defined prior to xorp being started. I have more testing to do but it looks good so far.

Thanks,

David
----- Original Message -----
From: "Pavlin Radoslavov" <pavlin at ICSI.Berkeley.EDU>
To: "David Bond" <david.bond at themis.com>
Cc: "xorp-users" <xorp-users at xorp.org>
Sent: Monday, March 17, 2008 9:08:54 AM (GMT-0800) America/Los_Angeles
Subject: Re: [Xorp-users] Configuration Issue with pseudo interfaces 

David Bond <david.bond at themis.com> wrote:

> I'm trying to configure xorp to use a number of pseudo interfaces. However, when xorp is started, I get the following error:
> 
> bash-2.05b# /usr/local/xorp/bin/xorp_rtrmgr -b /mnt/jffs2/config.boot
> [ 1969/12/31 19:48:03  ERROR xorp_rtrmgr:1400 RTRMGR +330 main_rtrmgr.cc run ] rtrmgr shutting down due to an init error: PARSE ERROR [Config File /mnt/jffs2/config.boot, line 18]: syntax error; Last symbol parsed was "bond0"
> 
> It appears that xorp does not like the syntax bond0:1 for the pseudo interface. Any suggestions, thoughts, or comments.  I am not committed to using pseudo interfaces, but I do need to have the ability to have 2 physical interfaces that can respond to up to 3 different sub-nets, and a total of 5 different IP addresses.

What is the output of the "ip addr" Linux command?
I guess that the "bond0:1" pseudo interface corresponds to an alias
IP address, so you might try to use "bond0" instead.
If you don't want XORP to use some of the IP alias addresses
configured on bond0, then you should explicitly configure only those
IP addresses you want to use.

Regards,
Pavlin

> /* $XORP: xorp/rtrmgr/config.boot.sample,v 1.46 2007/03/12 10:16:05 atanu Exp $
> */
> 
> 
> interfaces {
>     restore-original-config-on-shutdown: false
>     interface bond0 {
>         description: "lab network"
>         disable: false
>         /* default-system-config */
> interfaces {
>     restore-original-config-on-shutdown: false
>     interface bond0 {
>         description: "lab network"
>         disable: false
>         /* default-system-config */
>         vif bond0 {
>             disable: false
>             address 10.250.61.253 {
>                 prefix-length: 24
>                 broadcast: 10.250.61.255
>                 disable: false
>             }
>           }
> ==>           vif bond0:1 {
>                disable: false
>                address 192.168.84.38 {
>                         prefix-length: 24
>                         broadcast: 192.168.84.255
>                         disable: false
>             }
>           }
>         }
> 
> Thank you,
> David
> -- 
> *********************************************************************
> David Bond
> Themis Computer
> 47200 Bayside Parkway
> Fremont, CA 94538
> 
> Telephone: +1-510-252-0870
> Fax: +1-510-490-5529
> *********************************************************************
>                               No matter where you go, there you are
>                                                                             - B. Banzai
> *********************************************************************
> 
> _______________________________________________
> Xorp-users mailing list
> Xorp-users at xorp.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users


-- 
*********************************************************************
David Bond
Themis Computer
47200 Bayside Parkway
Fremont, CA 94538

Telephone: +1-510-252-0870
Fax: +1-510-490-5529
*********************************************************************
                              No matter where you go, there you are
                                                                            - B. Banzai
*********************************************************************


From dscher at mitre.org  Mon Mar 17 14:06:21 2008
From: dscher at mitre.org (Scher, Dave)
Date: Mon, 17 Mar 2008 17:06:21 -0400
Subject: [Xorp-users] OSPFv3 Redistribution into BGP
Message-ID: <9472CDDE9370AF4C871D40FD2ADB92BC026FF208@IMCSRV1.MITRE.ORG>

Hello,
    Thanks for the help with the configuration file to those who sent
email.  I am working in an environment where I need to redistribute
OSPFv3 (OSPF6) prefixes into BGP.  Is there currently a way in which to
do this?  I checked the XORP shell and when I tried to create a policy
statement term there was no protocol related entry for ospf6, though
RIPng was supported.  Any time table for support of OSPFv3 redistro?  
 
Thanks.
Dave Scher
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20080317/42c0abd3/attachment.html 

From yueli.m at gmail.com  Mon Mar 17 21:08:17 2008
From: yueli.m at gmail.com (Yue Li)
Date: Tue, 18 Mar 2008 00:08:17 -0400
Subject: [Xorp-users] Routes redistribution between OSPF and BGP
Message-ID: <49567c360803172108j6f728e5ds4423fe7eda633808@mail.gmail.com>

Hi, All
I have several XORP routers which form 2 Autonomous Systems.
OSPFv2 is used for intra-AS protocol and BGP is running on the AS
border routers.

I found no BGP routes when monitoring BGP behaviors, while their
peering relations are correct.
And routers in different AS can't ping each other.

So I guess I need to add routes redistribution to the configuration of
the AS border routers, right?
Do I need to add ospf-to-bgp policy, or bgp-to-ospf policy, or both of them?

Any help would be greatly appreciated.


From yueli.m at gmail.com  Wed Mar 19 09:26:07 2008
From: yueli.m at gmail.com (Yue Li)
Date: Wed, 19 Mar 2008 12:26:07 -0400
Subject: [Xorp-users] OSPF terminated with signal 6.
In-Reply-To: <52460.1205268877@tigger.icir.org>
References: <yueli.m@gmail.com>
	<49567c360803070938v375eb5a9oc4df656f76fb0835@mail.gmail.com>
	<52460.1205268877@tigger.icir.org>
Message-ID: <49567c360803190926w51c1baa2nc2e54c4553707883@mail.gmail.com>

Hi, Atanu
The ospf seems to be shutdown again. I have 245 xorp instances
running, only one has this problem.
And rib, rtrmgr, fea and policy are fine.

[ 2008/03/19 11:50:45  ERROR xorp_rtrmgr:18144 RTRMGR +747
module_manager.cc done_cb ] Command "/local/xorp/ospf/xorp_ospfv2":
terminated with signal 6.

[ 2008/03/19 11:50:45  ERROR xorp_fea:18146 LIBXORP +213
buffered_asyncio.cc io_event ] read error 104
[ 2008/03/19 11:50:45  ERROR xorp_fea:18146 XRL +159 xrl_pf_stcp.cc
read_event ] Read failed (error = 104)
[ 2008/03/19 11:50:45  ERROR xorp_fea:18146 XRL +338 xrl_pf_stcp.cc
die ] STCPRequestHandler died: read error
[ 2008/03/19 11:50:45  FATAL xorp_ospfv2:20010 OSPF +2467
area_router.cc maxage_reached ] LSA not in database: Summary-LSA:
LS age 3600 Options  0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x4
Link State ID 10.0.1.34 Advertising Router 10.0.0.85 LS sequence
number 0x80000001 LS checksum 0xe2bf length 28
        Network Mask 0
        Metric 300

[ 2008/03/19 11:50:45 INFO xorp_fea XRL ] Sender died (protocol =
"stcp", address = "127.0.0.1:47939")
[ 2008/03/19 11:50:45  ERROR xorp_fea:18146 LIBXORP +213
buffered_asyncio.cc io_event ] read error 111
[ 2008/03/19 11:50:45  ERROR xorp_fea:18146 XRL +782 xrl_pf_stcp.cc
read_event ] Read failed (error = 111)
[ 2008/03/19 11:50:45  ERROR xorp_fea:18146 XRL +635 xrl_pf_stcp.cc
die ] XrlPFSTCPSender died: read error
[ 2008/03/19 11:50:45 INFO xorp_rib RIB ] Received death event for
protocol ospfv2 shutting down -------



On Tue, Mar 11, 2008 at 4:54 PM, Atanu Ghosh <atanu at icsi.berkeley.edu> wrote:
> Hi,
>
>  You found a bug which is now fixed in CVS:
>  <http://mailman.icsi.berkeley.edu/pipermail/xorp-cvs/2008-March/010790.html>
>
>  I think that during the database exchange the last LSA in the database
>  was invalidated, an attempt was then made to get the next LSA when no
>  more were present.
>
>         Atanu.
>
>  >>>>> "Yue" == Yue Li <yueli.m at gmail.com> writes:
>
>     Yue> Hi, All The ospfv2 module is terminated with signal 6.  I got
>     Yue> the following error msg: [ 2008/03/07 11:55:06 FATAL
>     Yue> xorp_ospfv2:3279 OSPF +2964 area_router.cc get_entry_database ]
>     Yue> Index too far 72 length 72
>
>     Yue> I have several xorp instances running, they have similar config
>     Yue> files, but only one is terminated abnormally (above), others
>     Yue> run well.
>
>     Yue> Could anyone give some clues?
>
>     Yue> Thanks a lot!
>
>     Yue> _______________________________________________ Xorp-users
>     Yue> mailing list Xorp-users at xorp.org
>     Yue> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users
>


From greearb at candelatech.com  Wed Mar 19 10:02:36 2008
From: greearb at candelatech.com (Ben Greear)
Date: Wed, 19 Mar 2008 10:02:36 -0700
Subject: [Xorp-users] OSPF terminated with signal 6.
In-Reply-To: <49567c360803190926w51c1baa2nc2e54c4553707883@mail.gmail.com>
References: <yueli.m@gmail.com>	<49567c360803070938v375eb5a9oc4df656f76fb0835@mail.gmail.com>	<52460.1205268877@tigger.icir.org>
	<49567c360803190926w51c1baa2nc2e54c4553707883@mail.gmail.com>
Message-ID: <47E1472C.4050609@candelatech.com>

Yue Li wrote:
> Hi, Atanu
> The ospf seems to be shutdown again. I have 245 xorp instances
> running, only one has this problem.
> And rib, rtrmgr, fea and policy are fine.

> [ 2008/03/19 11:50:45  FATAL xorp_ospfv2:20010 OSPF +2467
> area_router.cc maxage_reached ] LSA not in database: Summary-LSA:
> LS age 3600 Options  0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x4
> Link State ID 10.0.1.34 Advertising Router 10.0.0.85 LS sequence
> number 0x80000001 LS checksum 0xe2bf length 28
>         Network Mask 0
>         Metric 300

I've seen this one as well, and opened a bug in the bug tracker
a few days ago...

Are you somehow virtualizing Xorp, or do you have 245 machines
running xorp?

Thanks,
Ben

-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


From atanu at ICSI.Berkeley.EDU  Wed Mar 19 10:07:25 2008
From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh)
Date: Wed, 19 Mar 2008 10:07:25 -0700
Subject: [Xorp-users] OSPF terminated with signal 6.
In-Reply-To: Message from Ben Greear <greearb@candelatech.com> 
	of "Wed, 19 Mar 2008 10:02:36 PDT." <47E1472C.4050609@candelatech.com> 
Message-ID: <76892.1205946445@tigger.icir.org>

Hi,

I have found an issue that may be causing this problem I will check in
the fix today. I didn't check in the fix earlier because I have been
unable to reproduce the problem.

       Atanu.

>>>>> "Ben" == Ben Greear <greearb at candelatech.com> writes:

    Ben> Yue Li wrote:

    >> Hi, Atanu The ospf seems to be shutdown again. I have 245 xorp
    >> instances running, only one has this problem.  And rib, rtrmgr,
    >> fea and policy are fine.

    >> [ 2008/03/19 11:50:45 FATAL xorp_ospfv2:20010 OSPF +2467
    >> area_router.cc maxage_reached ] LSA not in database: Summary-LSA:
    >> LS age 3600 Options 0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x4
    >> Link State ID 10.0.1.34 Advertising Router 10.0.0.85 LS sequence
    >> number 0x80000001 LS checksum 0xe2bf length 28 Network Mask 0
    >> Metric 300

    Ben> I've seen this one as well, and opened a bug in the bug tracker
    Ben> a few days ago...

    Ben> Are you somehow virtualizing Xorp, or do you have 245 machines
    Ben> running xorp?

    Ben> Thanks, Ben

    Ben> -- Ben Greear <greearb at candelatech.com> Candela Technologies
    Ben> Inc http://www.candelatech.com


From greearb at candelatech.com  Wed Mar 19 10:11:33 2008
From: greearb at candelatech.com (Ben Greear)
Date: Wed, 19 Mar 2008 10:11:33 -0700
Subject: [Xorp-users] OSPF terminated with signal 6.
In-Reply-To: <76892.1205946445@tigger.icir.org>
References: <76892.1205946445@tigger.icir.org>
Message-ID: <47E14945.5080606@candelatech.com>

Atanu Ghosh wrote:
> Hi,
> 
> I have found an issue that may be causing this problem I will check in
> the fix today. I didn't check in the fix earlier because I have been
> unable to reproduce the problem.

I should be able to verify it quickly..I can usually generate several cores
in 15 minutes of running my 30-node scenario.

Thanks,
Ben

-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


From yueli.m at gmail.com  Wed Mar 19 10:15:46 2008
From: yueli.m at gmail.com (Yue Li)
Date: Wed, 19 Mar 2008 13:15:46 -0400
Subject: [Xorp-users] OSPF terminated with signal 6.
In-Reply-To: <76892.1205946445@tigger.icir.org>
References: <greearb@candelatech.com> <47E1472C.4050609@candelatech.com>
	<76892.1205946445@tigger.icir.org>
Message-ID: <49567c360803191015i123cec92s40fcac41a08949de@mail.gmail.com>

Yes, I'm hosting xorp by using virtual machines.
I plan to do some routing test with our network simulator.


On Wed, Mar 19, 2008 at 1:07 PM, Atanu Ghosh <atanu at icsi.berkeley.edu> wrote:
> Hi,
>
>  I have found an issue that may be causing this problem I will check in
>  the fix today. I didn't check in the fix earlier because I have been
>  unable to reproduce the problem.
>
>        Atanu.
>
>  >>>>> "Ben" == Ben Greear <greearb at candelatech.com> writes:
>
>
>     Ben> Yue Li wrote:
>
>     >> Hi, Atanu The ospf seems to be shutdown again. I have 245 xorp
>     >> instances running, only one has this problem.  And rib, rtrmgr,
>     >> fea and policy are fine.
>
>     >> [ 2008/03/19 11:50:45 FATAL xorp_ospfv2:20010 OSPF +2467
>     >> area_router.cc maxage_reached ] LSA not in database: Summary-LSA:
>     >> LS age 3600 Options 0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x4
>     >> Link State ID 10.0.1.34 Advertising Router 10.0.0.85 LS sequence
>     >> number 0x80000001 LS checksum 0xe2bf length 28 Network Mask 0
>     >> Metric 300
>
>     Ben> I've seen this one as well, and opened a bug in the bug tracker
>     Ben> a few days ago...
>
>     Ben> Are you somehow virtualizing Xorp, or do you have 245 machines
>     Ben> running xorp?
>
>     Ben> Thanks, Ben
>
>
>     Ben> -- Ben Greear <greearb at candelatech.com> Candela Technologies
>     Ben> Inc http://www.candelatech.com
>
>


From atanu at ICSI.Berkeley.EDU  Wed Mar 19 15:50:59 2008
From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh)
Date: Wed, 19 Mar 2008 15:50:59 -0700
Subject: [Xorp-users] OSPF terminated with signal 6.
In-Reply-To: Message from Ben Greear <greearb@candelatech.com> 
	of "Wed, 19 Mar 2008 10:11:33 PDT." <47E14945.5080606@candelatech.com> 
Message-ID: <4433.1205967059@tigger.icir.org>

Hi,

Could you try this fix?

      Atanu.

Revision  Changes                              Path
1.296     +3 -3;  commitid: ed9647e196bc41a7;  xorp/ospf/area_router.cc
1.111     +8 -3;  commitid: ed9647e196bc41a7;  xorp/ospf/lsa.hh


>>>>> "Ben" == Ben Greear <greearb at candelatech.com> writes:

    Ben> Atanu Ghosh wrote:
    >> Hi, I have found an issue that may be causing this problem I will
    >> check in the fix today. I didn't check in the fix earlier because
    >> I have been unable to reproduce the problem.

    Ben> I should be able to verify it quickly..I can usually generate
    Ben> several cores in 15 minutes of running my 30-node scenario.

    Ben> Thanks, Ben

    Ben> -- Ben Greear <greearb at candelatech.com> Candela Technologies
    Ben> Inc http://www.candelatech.com


From greearb at candelatech.com  Wed Mar 19 23:29:25 2008
From: greearb at candelatech.com (Ben Greear)
Date: Wed, 19 Mar 2008 23:29:25 -0700
Subject: [Xorp-users] OSPF terminated with signal 6.
In-Reply-To: <4433.1205967059@tigger.icir.org>
References: <4433.1205967059@tigger.icir.org>
Message-ID: <47E20445.70206@candelatech.com>

Atanu Ghosh wrote:
> Hi,
>
> Could you try this fix?
>
>       Atanu.
>
> Revision  Changes                              Path
> 1.296     +3 -3;  commitid: ed9647e196bc41a7;  xorp/ospf/area_router.cc
> 1.111     +8 -3;  commitid: ed9647e196bc41a7;  xorp/ospf/lsa.hh
>   
I still see the assert, unfortunately.  I'll be happy to try any 
debugging patch
you might have if you need more info.  In the meantime, I think I'll change
it to a log msg instead of assert and just return from that method.

Thanks,
Ben



>
>   
>>>>>> "Ben" == Ben Greear <greearb at candelatech.com> writes:
>>>>>>             
>
>     Ben> Atanu Ghosh wrote:
>     >> Hi, I have found an issue that may be causing this problem I will
>     >> check in the fix today. I didn't check in the fix earlier because
>     >> I have been unable to reproduce the problem.
>
>     Ben> I should be able to verify it quickly..I can usually generate
>     Ben> several cores in 15 minutes of running my 30-node scenario.
>
>     Ben> Thanks, Ben
>
>     Ben> -- Ben Greear <greearb at candelatech.com> Candela Technologies
>     Ben> Inc http://www.candelatech.com
>   


-- 
Ben Greear <greearb at candelatech.com> 
Candela Technologies Inc  http://www.candelatech.com



From greearb at candelatech.com  Thu Mar 20 00:20:17 2008
From: greearb at candelatech.com (Ben Greear)
Date: Thu, 20 Mar 2008 00:20:17 -0700
Subject: [Xorp-users] OSPF terminated with signal 6.
In-Reply-To: <47E20445.70206@candelatech.com>
References: <4433.1205967059@tigger.icir.org> <47E20445.70206@candelatech.com>
Message-ID: <47E21031.10205@candelatech.com>

Ben Greear wrote:
> Atanu Ghosh wrote:
>   
>> Hi,
>>
>> Could you try this fix?
>>
>>       Atanu.
>>
>> Revision  Changes                              Path
>> 1.296     +3 -3;  commitid: ed9647e196bc41a7;  xorp/ospf/area_router.cc
>> 1.111     +8 -3;  commitid: ed9647e196bc41a7;  xorp/ospf/lsa.hh
>>   
>>     
> I still see the assert, unfortunately.  I'll be happy to try any 
> debugging patch
> you might have if you need more info.  In the meantime, I think I'll change
> it to a log msg instead of assert and just return from that method.
>   
Sorry, please ignore this.  I was running a stale build without your fix.

I still didn't get a clean run, but the problem appears to be with a piece
of code I just put in...will test it again tomorrow when I'm fresh and
let you know how that goes.

Thanks,
Ben

-- 
Ben Greear <greearb at candelatech.com> 
Candela Technologies Inc  http://www.candelatech.com



From pavlin at ICSI.Berkeley.EDU  Thu Mar 20 08:43:42 2008
From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov)
Date: Thu, 20 Mar 2008 08:43:42 -0700
Subject: [Xorp-users] OSPF terminated with signal 6.
In-Reply-To: <49567c360803190926w51c1baa2nc2e54c4553707883@mail.gmail.com> 
References: <yueli.m@gmail.com>
	<49567c360803070938v375eb5a9oc4df656f76fb0835@mail.gmail.com>
	<52460.1205268877@tigger.icir.org>
	<49567c360803190926w51c1baa2nc2e54c4553707883@mail.gmail.com>
Message-ID: <200803201543.m2KFhgjT010203@fruitcake.ICSI.Berkeley.EDU>

Yue Li <yueli.m at gmail.com> wrote:

> Hi, Atanu
> The ospf seems to be shutdown again. I have 245 xorp instances
                                       ~~~~~~~~~~~~~~~~~~~~~~~~~

This is off-topic, but at some stage we would like to know more
about how you are doing that :)

Thanks,
Pavlin

> running, only one has this problem.
> And rib, rtrmgr, fea and policy are fine.


From yueli.m at gmail.com  Thu Mar 20 08:54:03 2008
From: yueli.m at gmail.com (Yue Li)
Date: Thu, 20 Mar 2008 11:54:03 -0400
Subject: [Xorp-users] OSPF terminated with signal 6.
In-Reply-To: <200803201543.m2KFhgjT010203@fruitcake.ICSI.Berkeley.EDU>
References: <yueli.m@gmail.com>
	<49567c360803070938v375eb5a9oc4df656f76fb0835@mail.gmail.com>
	<52460.1205268877@tigger.icir.org>
	<49567c360803190926w51c1baa2nc2e54c4553707883@mail.gmail.com>
	<200803201543.m2KFhgjT010203@fruitcake.ICSI.Berkeley.EDU>
Message-ID: <49567c360803200854wc5f6e83v84027a7e6ae274f0@mail.gmail.com>

We are doing a project on integrating XORP with our real-time network
simulator (PRIME).
We use virtual machine to host multiple XORP instances, you could find
more information
about our projects here:
http://lynx.cis.fiu.edu:8000/twiki/bin/view/Public/WebHome

- Yue Li

On Thu, Mar 20, 2008 at 11:43 AM, Pavlin Radoslavov
<pavlin at icsi.berkeley.edu> wrote:
> Yue Li <yueli.m at gmail.com> wrote:
>
>  > Hi, Atanu
>  > The ospf seems to be shutdown again. I have 245 xorp instances
>                                        ~~~~~~~~~~~~~~~~~~~~~~~~~
>
>  This is off-topic, but at some stage we would like to know more
>  about how you are doing that :)
>
>  Thanks,
>  Pavlin
>
>
>
>  > running, only one has this problem.
>  > And rib, rtrmgr, fea and policy are fine.
>


From greearb at candelatech.com  Thu Mar 20 17:36:10 2008
From: greearb at candelatech.com (Ben Greear)
Date: Thu, 20 Mar 2008 17:36:10 -0700
Subject: [Xorp-users] OSPF terminated with signal 6.
In-Reply-To: <4433.1205967059@tigger.icir.org>
References: <4433.1205967059@tigger.icir.org>
Message-ID: <47E302FA.2040008@candelatech.com>

Atanu Ghosh wrote:
> Hi,
> 
> Could you try this fix?

Ok, I tried again, and this time I'm quite sure I have your
patch applied properly.  I still get the assert.

I modified the code to just print a warning and then goto the bottom
of the method.  I'm not sure if my patch is right or not, but it doesn't
help much.  See farther down for log messages and a new assert relating
to index mismatch.

[area_router.cc]
@@ -2702,8 +2702,10 @@

      XLOG_ASSERT(!lsar->external());

-    if (!find_lsa(lsar, index))
-       XLOG_FATAL("LSA not in database: %s", cstring(*lsar));
+    if (!find_lsa(lsar, index)) {
+       XLOG_WARNING("LSA not in database: %s", cstring(*lsar));
+       goto out;
+    }

      if (i != index)
         XLOG_FATAL("Indexes don't match %u != %u %s",  XORP_UINT_CAST(i),
@@ -2726,6 +2728,7 @@
  #endif
      publish_all(lsar);

+  out:
      // Clear the timer otherwise there is a circular dependency.
      // The LSA contains a XorpTimer that points back to the LSA.
      lsar->get_timer().clear();


I'm not sure if this is due to my patch above, or if there are also index
issues.

[ 2008/03/20 17:26:34  WARNING xorp_ospfv2:26077 OSPF area_router.cc:2706 maxage_reached ] LSA not in database: Network-LSA:
LS age 3600 Options  0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x2 Link State ID 10.25.28.28 Advertising Router 127.1.0.28 LS sequence number 0x80000001 LS checksum 0xda51 length 32
         Network Mask 0xffffff00
         Attached Router 127.1.0.28
         Attached Router 127.1.0.25
[ 2008/03/20 17:26:34  FATAL xorp_ospfv2:26077 OSPF area_router.cc:2713 maxage_reached ] Indexes don't match 167 != 141 Network-LSA:
LS age   90 Options  0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x2 Link State ID 10.24.28.28 Advertising Router 127.1.0.28 LS sequence number 0x80000001 LS checksum 0xd855 length 32
         Network Mask 0xffffff00
         Attached Router 127.1.0.28
         Attached Router 127.1.0.24

This appears to happen when lots of xorp nodes are being joined together
(ie, interfaces added connecting directly to other xorp routers).

Let me know if I can get you more debugging info.

Thanks,
Ben

-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


From atanu at ICSI.Berkeley.EDU  Fri Mar 21 09:08:47 2008
From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh)
Date: Fri, 21 Mar 2008 09:08:47 -0700
Subject: [Xorp-users] OSPF terminated with signal 6.
In-Reply-To: Message from Ben Greear <greearb@candelatech.com> 
	of "Thu, 20 Mar 2008 17:36:10 PDT." <47E302FA.2040008@candelatech.com> 
Message-ID: <6785.1206115727@tigger.icir.org>

Hi,

Let me explain in *general* terms how this code works.

Each area in OSPF contains an LSA database for the purposes of this
discussion there are two kinds of LSAs ones that the router generated
and ones that it received. Each LSA contains a single timer if the LSA
was received from another router them the timer is set to MaxAge
(default 1 hour), so if after MaxAge the LSA has not been refreshed it
will be removed. If the router is generating an LSA itself the timer
is set to LSRefreshTime (default 30 minutes).

The LSAs database is stored in a STL vector in effect an array there
are a number of requirements such as database exchange that made this
a reasonable choice. There is a single method to add an LSA to the
database and a single method to remove an LSA from the database. When
a LSA is removed from the database then the timer associated with it
should be unconditionally cancelled, my previous fix closed a hole
where under special circumstances the timer would not be cancelled.

As a sanity check when a timer is primed it is given its index in the
database. What you are seeing is the MaxAge timer firing on an LSA
that is no longer in the database, which should not be possible. The
first test verifies that the LSA is still in the database, which it
isn't and then the second test verifies that the LSA is at the correct
position which obviously it isn't.

In order to keep OSPF running your best bet is to just print a warning
and return from this method when the LSA is not found in the database,
all the other code in this method is basically to remove the LSA from
the database and notify the neighbours that this LSA should be
removed. The code that notifies that neigbours also contains sanity
checks that will probably be tripped.

An LSA with an AGE of MaxAge has to be handled specially so the
problem probably lies in this special handling in an other part of the
code. The way to remove an LSA from the OSPF database is to send it
out with an AGE of MaxAge, there may be a problem with the handling of
an incoming LSA with AGE set to MaxAge.

When I find something I'll send you a patch to try.

   Atanu.

>>>>> "Ben" == Ben Greear <greearb at candelatech.com> writes:

    Ben> Atanu Ghosh wrote:
    >> Hi,
    >> Could you try this fix?

    Ben> Ok, I tried again, and this time I'm quite sure I have your
    Ben> patch applied properly.  I still get the assert.

    Ben> I modified the code to just print a warning and then goto the bottom
    Ben> of the method.  I'm not sure if my patch is right or not, but it doesn't
    Ben> help much.  See farther down for log messages and a new assert relating
    Ben> to index mismatch.

    Ben> [area_router.cc]
    Ben> @@ -2702,8 +2702,10 @@

    Ben> XLOG_ASSERT(!lsar->external());

    Ben> -    if (!find_lsa(lsar, index))
    Ben> -       XLOG_FATAL("LSA not in database: %s", cstring(*lsar));
    Ben> +    if (!find_lsa(lsar, index)) {
    Ben> +       XLOG_WARNING("LSA not in database: %s", cstring(*lsar));
    Ben> +       goto out;
    Ben> +    }

    Ben> if (i != index)
    Ben> XLOG_FATAL("Indexes don't match %u != %u %s",  XORP_UINT_CAST(i),
    Ben> @@ -2726,6 +2728,7 @@
    Ben> #endif
    Ben> publish_all(lsar);

    Ben> +  out:
    Ben> // Clear the timer otherwise there is a circular dependency.
    Ben> // The LSA contains a XorpTimer that points back to the LSA.
    lsar-> get_timer().clear();


    Ben> I'm not sure if this is due to my patch above, or if there are also index
    Ben> issues.

    Ben> [ 2008/03/20 17:26:34  WARNING xorp_ospfv2:26077 OSPF area_router.cc:2706 maxage_reached ] LSA not in database: Network-LSA:
    Ben> LS age 3600 Options  0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x2 Link State ID 10.25.28.28 Advertising Router 127.1.0.28 LS sequence number 0x80000001 LS checksum 0xda51 length 32
    Ben> Network Mask 0xffffff00
    Ben> Attached Router 127.1.0.28
    Ben> Attached Router 127.1.0.25
    Ben> [ 2008/03/20 17:26:34  FATAL xorp_ospfv2:26077 OSPF area_router.cc:2713 maxage_reached ] Indexes don't match 167 != 141 Network-LSA:
    Ben> LS age   90 Options  0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x2 Link State ID 10.24.28.28 Advertising Router 127.1.0.28 LS sequence number 0x80000001 LS checksum 0xd855 length 32
    Ben> Network Mask 0xffffff00
    Ben> Attached Router 127.1.0.28
    Ben> Attached Router 127.1.0.24

    Ben> This appears to happen when lots of xorp nodes are being joined together
    Ben> (ie, interfaces added connecting directly to other xorp routers).

    Ben> Let me know if I can get you more debugging info.

    Ben> Thanks,
    Ben> Ben

    Ben> -- 
    Ben> Ben Greear <greearb at candelatech.com>
    Ben> Candela Technologies Inc  http://www.candelatech.com


From greearb at candelatech.com  Fri Mar 21 10:28:03 2008
From: greearb at candelatech.com (Ben Greear)
Date: Fri, 21 Mar 2008 10:28:03 -0700
Subject: [Xorp-users] OSPF terminated with signal 6.
In-Reply-To: <6785.1206115727@tigger.icir.org>
References: <6785.1206115727@tigger.icir.org>
Message-ID: <47E3F023.5000607@candelatech.com>

Atanu Ghosh wrote:

> An LSA with an AGE of MaxAge has to be handled specially so the
> problem probably lies in this special handling in an other part of the
> code. The way to remove an LSA from the OSPF database is to send it
> out with an AGE of MaxAge, there may be a problem with the handling of
> an incoming LSA with AGE set to MaxAge.
> 
> When I find something I'll send you a patch to try.

Thanks for the explanation.  In my case, none of the xorp processes have
been running for more than about 15 minutes, so it must be this special
handling you mentioned...

Thanks,
Ben

-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


From atanu at ICSI.Berkeley.EDU  Fri Mar 21 21:25:44 2008
From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh)
Date: Fri, 21 Mar 2008 21:25:44 -0700
Subject: [Xorp-users] OSPFv3 Redistribution into BGP
In-Reply-To: Message from "Scher, Dave" <dscher@mitre.org> of "Mon,
	17 Mar 2008 17:06:21 EDT."
	<9472CDDE9370AF4C871D40FD2ADB92BC026FF208@IMCSRV1.MITRE.ORG> 
Message-ID: <58718.1206159944@tigger.icir.org>

Hi,

All the XORP unicast protocols support policy and hence redistribution.

There was an ommission in a template file that stopped redistribution for
OSPFv3 being configured.

I have just checked in the fix.

       Atanu.

Revision  Changes                             Path
1.25      +2 -1;  commitid: 82c47e48a0241a7;  xorp/etc/templates/policy.tp

>>>>> "Dave" == Dave Scher <Scher> writes:

    Dave>    Hello,

    Dave>        Thanks for the help with the configuration file to
    Dave> those who sent email.  I am working in an environment where I
    Dave> need to redistribute OSPFv3 (OSPF6) prefixes into BGP.  Is
    Dave> there currently a way in which to do this?  I checked the XORP
    Dave> shell and when I tried to create a policy statement term there
    Dave> was no protocol related entry for ospf6, though RIPng was
    Dave> supported.  Any time table for support of OSPFv3 redistro?



    Dave>    Thanks.  Dave Scher
    Dave> _______________________________________________ Xorp-users
    Dave> mailing list Xorp-users at xorp.org
    Dave> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users


From yuki.latt at gmail.com  Sat Mar 22 03:17:26 2008
From: yuki.latt at gmail.com (yuki latt)
Date: Sat, 22 Mar 2008 19:17:26 +0900
Subject: [Xorp-users] xorp on ubuntu 7.10 and QoS routing
Message-ID: <c402915a0803220317o7237b272j2333102da59ad38a@mail.gmail.com>

Dear all,

    Before downloading xorp, I'd like to ensure the following.

1) Does Xorp work on Ubuntu 7.10? In
http://www.xorp.org/releases/current/docs/BUILD_NOTES, I found only  Redhat,
Fedora and Debian.

If there is any other user who had experience with xorp on ubuntu, please
let me know the things I should know.

2)  Xorp supports bgp4 for both IPv4 and IPv6. At least for IP4, QoS_NLRI
attributed is already included ?

Thanks in advance,   :-)
yuki
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20080322/33d76365/attachment.html 

From pavlin at ICSI.Berkeley.EDU  Sat Mar 22 06:02:59 2008
From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov)
Date: Sat, 22 Mar 2008 06:02:59 -0700
Subject: [Xorp-users] xorp on ubuntu 7.10 and QoS routing
In-Reply-To: <c402915a0803220317o7237b272j2333102da59ad38a@mail.gmail.com> 
References: <c402915a0803220317o7237b272j2333102da59ad38a@mail.gmail.com>
Message-ID: <200803221302.m2MD2xeE001337@fruitcake.ICSI.Berkeley.EDU>

yuki latt <yuki.latt at gmail.com> wrote:

> Dear all,
> 
>     Before downloading xorp, I'd like to ensure the following.
> 
> 1) Does Xorp work on Ubuntu 7.10? In
> http://www.xorp.org/releases/current/docs/BUILD_NOTES, I found only  Redhat,
> Fedora and Debian.

Yes, it does, but you might have to get the latest code from
anon. CVS:

http://cvsweb.xorp.org/cgi-bin/cvsweb.cgi/xorp/BUILD_NOTES

The anon. CVS instructions are available from here:
http://www.xorp.org/cvs.html

> If there is any other user who had experience with xorp on ubuntu, please
> let me know the things I should know.
> 
> 2)  Xorp supports bgp4 for both IPv4 and IPv6. At least for IP4, QoS_NLRI
> attributed is already included ?

I will leave this question to the BGP folks :)

Regards,
Pavlin


From atanu at ICSI.Berkeley.EDU  Sun Mar 23 23:27:31 2008
From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh)
Date: Sun, 23 Mar 2008 23:27:31 -0700
Subject: [Xorp-users] xorp on ubuntu 7.10 and QoS routing
In-Reply-To: Message from "yuki latt" <yuki.latt@gmail.com> of "Sat,
	22 Mar 2008 19:17:26 +0900."
	<c402915a0803220317o7237b272j2333102da59ad38a@mail.gmail.com> 
Message-ID: <14721.1206340051@tigger.icir.org>

Hi,

In answer to your BGP questions both IPv4 and IPv6 are supported. 

With respect to QOS_NLRI I assume that we are talking about
draft-jacquenet-qos-nlri-05, we do not support this attribute? Is this
attribute being used the draft expired in December 2003?

    Atanu.

>>>>> "yuki" == yuki latt <yuki.latt at gmail.com> writes:

    yuki> Dear all,
    yuki> Before downloading xorp, I'd like to ensure the following.
    yuki> 1) Does Xorp work on Ubuntu 7.10? In
    yuki> http://www.xorp.org/releases/current/docs/BUILD_NOTES, I found only
    yuki> Redhat, Fedora and Debian.
    yuki> If there is any other user who had experience with xorp on ubuntu,
    yuki> please let me know the things I should know.
    yuki> 2)  Xorp supports bgp4 for both IPv4 and IPv6. At least for IP4,
    yuki> QoS_NLRI attributed is already included ?
    yuki> Thanks in advance,   :-)
    yuki> yuki
    yuki> _______________________________________________
    yuki> Xorp-users mailing list
    yuki> Xorp-users at xorp.org
    yuki> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users


From yuki.latt at gmail.com  Sun Mar 23 23:41:55 2008
From: yuki.latt at gmail.com (yuki latt)
Date: Mon, 24 Mar 2008 15:41:55 +0900
Subject: [Xorp-users] xorp on ubuntu 7.10 and QoS routing
In-Reply-To: <14721.1206340051@tigger.icir.org>
References: <yuki.latt@gmail.com>
	<c402915a0803220317o7237b272j2333102da59ad38a@mail.gmail.com>
	<14721.1206340051@tigger.icir.org>
Message-ID: <c402915a0803232341r1331b8eevc79700b839235c2f@mail.gmail.com>

Dear all,

     Thank you so much for your replies. :)

To Mr. Atanu,

     Thanks for your reply. Yes, I am talking about QoS_NLRI attribute of
draft-jacquenet-qos-nlri-05 and it is already expired. :-( But I'd like to
implement 'extended BGP' which can carry QoS information and thus, try to
put QoS information into that attribute (QoS_NLRI). Do you have any
suggestion or recommendation whether I should implement that attribute in
existing xorp? Although I cannot surely say mine will become QBGP , I am
really keen to do it.

    I am also considering about quagga. The main interest is which one will
be convenient and easy to implement. :D

regards,
yuki


On Mon, Mar 24, 2008 at 3:27 PM, Atanu Ghosh <atanu at icsi.berkeley.edu>
wrote:

> Hi,
>
> In answer to your BGP questions both IPv4 and IPv6 are supported.
>
> With respect to QOS_NLRI I assume that we are talking about
> draft-jacquenet-qos-nlri-05, we do not support this attribute? Is this
> attribute being used the draft expired in December 2003?
>
>    Atanu.
>
> >>>>> "yuki" == yuki latt <yuki.latt at gmail.com> writes:
>
>    yuki> Dear all,
>    yuki> Before downloading xorp, I'd like to ensure the following.
>    yuki> 1) Does Xorp work on Ubuntu 7.10? In
>    yuki> http://www.xorp.org/releases/current/docs/BUILD_NOTES, I found
> only
>    yuki> Redhat, Fedora and Debian.
>    yuki> If there is any other user who had experience with xorp on
> ubuntu,
>    yuki> please let me know the things I should know.
>    yuki> 2)  Xorp supports bgp4 for both IPv4 and IPv6. At least for IP4,
>    yuki> QoS_NLRI attributed is already included ?
>    yuki> Thanks in advance,   :-)
>    yuki> yuki
>    yuki> _______________________________________________
>    yuki> Xorp-users mailing list
>    yuki> Xorp-users at xorp.org
>    yuki> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20080324/779edb84/attachment.html 

From atanu at ICSI.Berkeley.EDU  Sun Mar 23 23:58:07 2008
From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh)
Date: Sun, 23 Mar 2008 23:58:07 -0700
Subject: [Xorp-users] xorp on ubuntu 7.10 and QoS routing
In-Reply-To: Message from "yuki latt" <yuki.latt@gmail.com> of "Mon,
	24 Mar 2008 15:41:55 +0900."
	<c402915a0803232341r1331b8eevc79700b839235c2f@mail.gmail.com> 
Message-ID: <18253.1206341887@tigger.icir.org>

Hi,

If you want to add the QOS_NLRI attribute to BGP then look at
bgp/path_attribute.cc and bgp/path_attribute.hh. Select a path attribute
type add it to PathAttType, use one of the other path attributes as a
guide such as OriginAttribute and create your own class, this should get
you most of the way. How you are going to set or use the QOS values is a
separate matter.

    Atanu.

>>>>> "yuki" == yuki latt <yuki.latt at gmail.com> writes:

    yuki> Dear all,
    yuki> Thank you so much for your replies. :)
    yuki> To Mr. Atanu,
    yuki> Thanks for your reply. Yes, I am talking about QoS_NLRI attribute
    yuki> of draft-jacquenet-qos-nlri-05 and it is already expired. :-( But I'd
    yuki> like to implement 'extended BGP' which can carry QoS information and
    yuki> thus, try to put QoS information into that attribute (QoS_NLRI). Do
    yuki> you have any suggestion or recommendation whether I should implement
    yuki> that attribute in existing xorp? Although I cannot surely say mine
    yuki> will become QBGP , I am really keen to do it.

    yuki> I am also considering about quagga. The main interest is which one
    yuki> will be convenient and easy to implement. :D
    yuki> regards,
    yuki> yuki

    yuki> On Mon, Mar 24, 2008 at 3:27 PM, Atanu Ghosh <atanu at icsi.berkeley.edu>
    yuki> wrote:

    yuki> Hi,
    yuki> In answer to your BGP questions both IPv4 and IPv6 are supported.
    yuki> With respect to QOS_NLRI I assume that we are talking about
    yuki> draft-jacquenet-qos-nlri-05, we do not support this attribute? Is
    yuki> this
    yuki> attribute being used the draft expired in December 2003?
    yuki> Atanu.
    >>>>>> "yuki" == yuki latt <yuki.latt at gmail.com> writes:
    yuki> Dear all,
    yuki> Before downloading xorp, I'd like to ensure the following.
    yuki> 1) Does Xorp work on Ubuntu 7.10? In
    yuki> http://www.xorp.org/releases/current/docs/BUILD_NOTES, I
    yuki> found only
    yuki> Redhat, Fedora and Debian.
    yuki> If there is any other user who had experience with xorp on
    yuki> ubuntu,
    yuki> please let me know the things I should know.
    yuki> 2)  Xorp supports bgp4 for both IPv4 and IPv6. At least
    yuki> for IP4,
    yuki> QoS_NLRI attributed is already included ?
    yuki> Thanks in advance,   :-)
    yuki> yuki
    yuki> _______________________________________________
    yuki> Xorp-users mailing list
    yuki> Xorp-users at xorp.org
    yuki> 
    yuki> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users
    yuki> _______________________________________________
    yuki> Xorp-users mailing list
    yuki> Xorp-users at xorp.org
    yuki> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users


From yuki.latt at gmail.com  Mon Mar 24 03:36:43 2008
From: yuki.latt at gmail.com (yuki latt)
Date: Mon, 24 Mar 2008 19:36:43 +0900
Subject: [Xorp-users] xorp on ubuntu 7.10 and QoS routing
In-Reply-To: <18253.1206341887@tigger.icir.org>
References: <yuki.latt@gmail.com>
	<c402915a0803232341r1331b8eevc79700b839235c2f@mail.gmail.com>
	<18253.1206341887@tigger.icir.org>
Message-ID: <c402915a0803240336u7b6ccab5w5f9e6ade5d3d6bae@mail.gmail.com>

Hello,

     Thank you. At first, I will try to use xorp on ubuntu and make myself
understand how BGP works. After that, implementation will be decided. ^^ Let
me ask you all later if I find some difficulty in using it.

thanks,
yuki

On Mon, Mar 24, 2008 at 3:58 PM, Atanu Ghosh <atanu at icsi.berkeley.edu>
wrote:

> Hi,
>
> If you want to add the QOS_NLRI attribute to BGP then look at
> bgp/path_attribute.cc and bgp/path_attribute.hh. Select a path attribute
> type add it to PathAttType, use one of the other path attributes as a
> guide such as OriginAttribute and create your own class, this should get
> you most of the way. How you are going to set or use the QOS values is a
> separate matter.
>
>    Atanu.
>
> >>>>> "yuki" == yuki latt <yuki.latt at gmail.com> writes:
>
>    yuki> Dear all,
>     yuki> Thank you so much for your replies. :)
>    yuki> To Mr. Atanu,
>    yuki> Thanks for your reply. Yes, I am talking about QoS_NLRI attribute
>    yuki> of draft-jacquenet-qos-nlri-05 and it is already expired. :-( But
> I'd
>    yuki> like to implement 'extended BGP' which can carry QoS information
> and
>    yuki> thus, try to put QoS information into that attribute (QoS_NLRI).
> Do
>    yuki> you have any suggestion or recommendation whether I should
> implement
>    yuki> that attribute in existing xorp? Although I cannot surely say
> mine
>    yuki> will become QBGP , I am really keen to do it.
>
>    yuki> I am also considering about quagga. The main interest is which
> one
>    yuki> will be convenient and easy to implement. :D
>    yuki> regards,
>    yuki> yuki
>
>    yuki> On Mon, Mar 24, 2008 at 3:27 PM, Atanu Ghosh <
> atanu at icsi.berkeley.edu>
>     yuki> wrote:
>
>    yuki> Hi,
>    yuki> In answer to your BGP questions both IPv4 and IPv6 are supported.
>    yuki> With respect to QOS_NLRI I assume that we are talking about
>    yuki> draft-jacquenet-qos-nlri-05, we do not support this attribute? Is
>    yuki> this
>    yuki> attribute being used the draft expired in December 2003?
>    yuki> Atanu.
>     >>>>>> "yuki" == yuki latt <yuki.latt at gmail.com> writes:
>    yuki> Dear all,
>    yuki> Before downloading xorp, I'd like to ensure the following.
>    yuki> 1) Does Xorp work on Ubuntu 7.10? In
>    yuki> http://www.xorp.org/releases/current/docs/BUILD_NOTES, I
>     yuki> found only
>     yuki> Redhat, Fedora and Debian.
>    yuki> If there is any other user who had experience with xorp on
>     yuki> ubuntu,
>     yuki> please let me know the things I should know.
>    yuki> 2)  Xorp supports bgp4 for both IPv4 and IPv6. At least
>     yuki> for IP4,
>     yuki> QoS_NLRI attributed is already included ?
>    yuki> Thanks in advance,   :-)
>    yuki> yuki
>    yuki> _______________________________________________
>    yuki> Xorp-users mailing list
>    yuki> Xorp-users at xorp.org
>    yuki>
>    yuki> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users
>    yuki> _______________________________________________
>    yuki> Xorp-users mailing list
>    yuki> Xorp-users at xorp.org
>    yuki> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20080324/7f07e24c/attachment.html 

From atanu at ICSI.Berkeley.EDU  Mon Mar 24 09:20:49 2008
From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh)
Date: Mon, 24 Mar 2008 09:20:49 -0700
Subject: [Xorp-users] Routes redistribution between OSPF and BGP
In-Reply-To: Message from "Yue Li" <yueli.m@gmail.com> of "Tue,
	18 Mar 2008 00:08:17 EDT."
	<49567c360803172108j6f728e5ds4423fe7eda633808@mail.gmail.com> 
Message-ID: <51243.1206375649@tigger.icir.org>

Hi,

All the networks that you wish to advertise to an external AS need to be
redistributed into BGP. You therefore need to redistribute OSPF into
BGP.

	Atanu.

>>>>> "Yue" == Yue Li <yueli.m at gmail.com> writes:

    Yue> Hi, All I have several XORP routers which form 2 Autonomous
    Yue> Systems.  OSPFv2 is used for intra-AS protocol and BGP is
    Yue> running on the AS border routers.

    Yue> I found no BGP routes when monitoring BGP behaviors, while
    Yue> their peering relations are correct.  And routers in different
    Yue> AS can't ping each other.

    Yue> So I guess I need to add routes redistribution to the
    Yue> configuration of the AS border routers, right?  Do I need to
    Yue> add ospf-to-bgp policy, or bgp-to-ospf policy, or both of them?

    Yue> Any help would be greatly appreciated.

    Yue> _______________________________________________ Xorp-users
    Yue> mailing list Xorp-users at xorp.org
    Yue> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users


From amaizuddin at yahoo.com  Tue Mar 25 10:41:07 2008
From: amaizuddin at yahoo.com (aizuddin ariffin)
Date: Tue, 25 Mar 2008 10:41:07 -0700 (PDT)
Subject: [Xorp-users] BGP route
Message-ID: <275830.90421.qm@web90301.mail.mud.yahoo.com>


Hi all.Can anyone help me check my BGP configuration?
Here is my configuration.This is my first time using
XORP and hope anyone can help me.
Thanks.

interfaces {
    interface eth0 {
 description: "data interface"
 vif eth0 {
     address 172.16.0.0 {
  prefix-length: 24
  broadcast: 172.16.0.255
     }
 }
    }
}

fea {
    unicast-forwarding4 {
    disable: true
   } 
}

policy {
 policy-statement export-connected {
 term 100 {
 from {
  protocol:"connected"
  network4: 172.16.0.0/24      
      }
 to   { 
  neighbor: 172.16.1.0
      }

 then { 
  nexthop4: 172.16.1.0
  accept
 }
}
}
}

protocols {
    bgp {
 bgp-id: 172.16.0.0
 local-as: 33333
 export: "export-connected" 

 peer 172.16.1.0 {
     local-ip: 172.16.0.0
     as: 33334
     next-hop: 172.16.1.0

     local-port: 179
     peer-port: 179
     holdtime: 120
     
 }
 
 peer 172.16.2.0 {
     local-ip: 172.16.0.0
     as: 33335
     next-hop: 172.16.2.0

     local-port: 179
     peer-port: 179
     holdtime: 120

 }

 peer 172.16.3.0 {
     local-ip: 172.16.0.1
     as: 33336
     next-hop: 172.16.3.0
     local-port: 179
     peer-port: 179
     holdtime: 120

     ipv4-unicast: true
     
     
 } 

 
    }
}

Here is my BGP output.

root at debian> show bgp routes
Status Codes: * valid route, > best route
Origin Codes: i IGP, e EGP, ? incomplete

Prefix             Nexthop     Peer       AS Path
*> 172.16.0.0/24  172.16.0.0  0.0.0.0        i

The output look something wrong to me though.
Can anyone help me solve this problem.Thanks.

       
---------------------------------
Never miss a thing.   Make Yahoo your homepage.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20080325/c125dc34/attachment.html 

From atanu at ICSI.Berkeley.EDU  Tue Mar 25 11:05:01 2008
From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh)
Date: Tue, 25 Mar 2008 11:05:01 -0700
Subject: [Xorp-users] BGP route
In-Reply-To: Message from aizuddin ariffin <amaizuddin@yahoo.com> of "Tue,
	25 Mar 2008 10:41:07 PDT."
	<275830.90421.qm@web90301.mail.mud.yahoo.com> 
Message-ID: <59130.1206468301@tigger.icir.org>

Hi,

The output of "show bgp routes" looks fine assuming that you have not
formed any peerings, or that the peers are not sending any routes.

       Atanu.

>>>>> "aizuddin" == aizuddin ariffin <amaizuddin at yahoo.com> writes:

    aizuddin> Hi all.Can anyone help me check my BGP configuration?
    aizuddin> Here is my configuration.This is my first time using
    aizuddin> XORP and hope anyone can help me.
    aizuddin> Thanks.
    aizuddin> interfaces {
    aizuddin> interface eth0 {
    aizuddin> description: "data interface"
    aizuddin> vif eth0 {
    aizuddin> address 172.16.0.0 {
    aizuddin> prefix-length: 24
    aizuddin> broadcast: 172.16.0.255
    aizuddin> }
    aizuddin> }
    aizuddin> }
    aizuddin> }
    aizuddin> fea {
    aizuddin> unicast-forwarding4 {
    aizuddin> disable: true
    aizuddin> } 
    aizuddin> }
    aizuddin> policy {
    aizuddin> policy-statement export-connected {
    aizuddin> term 100 {
    aizuddin> from {
    aizuddin> protocol:"connected"
    aizuddin> network4: 172.16.0.0/24      
    aizuddin> }
    aizuddin> to   { 
    aizuddin> neighbor: 172.16.1.0
    aizuddin> }
    aizuddin> then { 
    aizuddin> nexthop4: 172.16.1.0
    aizuddin> accept
    aizuddin> }
    aizuddin> }
    aizuddin> }
    aizuddin> }
    aizuddin> protocols {
    aizuddin> bgp {
    aizuddin> bgp-id: 172.16.0.0
    aizuddin> local-as: 33333
    aizuddin> export: "export-connected" 
    aizuddin> peer 172.16.1.0 {
    aizuddin> local-ip: 172.16.0.0
    aizuddin> as: 33334
    aizuddin> next-hop: 172.16.1.0
    aizuddin> local-port: 179
    aizuddin> peer-port:
    aizuddin> 179
    aizuddin> holdtime: 120
     
    aizuddin> }
 
    aizuddin> peer 172.16.2.0 {
    aizuddin> local-ip: 172.16.0.0
    aizuddin> as: 33335
    aizuddin> next-hop: 172.16.2.0
    aizuddin> local-port: 179
    aizuddin> peer-port: 179
    aizuddin> holdtime: 120
    aizuddin> }
    aizuddin> peer 172.16.3.0 {
    aizuddin> local-ip: 172.16.0.1
    aizuddin> as: 33336
    aizuddin> next-hop: 172.16.3.0
    aizuddin> local-port: 179
    aizuddin> peer-port: 179
    aizuddin> holdtime: 120
    aizuddin> ipv4-unicast: true
     
    aizuddin> } 
 
    aizuddin> }
    aizuddin> }
    aizuddin> Here is my BGP output.
    aizuddin> root at debian> show bgp routes
    aizuddin> Status Codes: * valid route, > best route
    aizuddin> Origin Codes: i IGP, e EGP, ? incomplete
    aizuddin> Prefix             Nexthop     Peer       AS Path
    aizuddin> *> 172.16.0.0/24  172.16.0.0  0.0.0.0        i
    aizuddin> The output look something wrong to me though.
    aizuddin> Can anyone help me solve this problem.Thanks.
    aizuddin> _________________________________________________________________

    aizuddin> Never miss a thing. Make Yahoo your homepage.
    aizuddin> _______________________________________________
    aizuddin> Xorp-users mailing list
    aizuddin> Xorp-users at xorp.org
    aizuddin> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users


From pavlin at ICSI.Berkeley.EDU  Tue Mar 25 11:27:17 2008
From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov)
Date: Tue, 25 Mar 2008 11:27:17 -0700
Subject: [Xorp-users] BGP route
In-Reply-To: <275830.90421.qm@web90301.mail.mud.yahoo.com> 
References: <275830.90421.qm@web90301.mail.mud.yahoo.com>
Message-ID: <200803251827.m2PIRHFU000916@fruitcake.ICSI.Berkeley.EDU>

aizuddin ariffin <amaizuddin at yahoo.com> wrote:

> 
> Hi all.Can anyone help me check my BGP configuration?
> Here is my configuration.This is my first time using
> XORP and hope anyone can help me.

This is not BGP-specific, but all your IP interface addresses have
form x.x.x.0. It is better to avoid the host part of the address
being zero which is the old-style broadcast address (now the subnet
address itself).

You should make all interface addreses x.x.x.1 or something like this.

Pavlin

> Thanks.
> 
> interfaces {
>     interface eth0 {
>  description: "data interface"
>  vif eth0 {
>      address 172.16.0.0 {
>   prefix-length: 24
>   broadcast: 172.16.0.255
>      }
>  }
>     }
> }
> 
> fea {
>     unicast-forwarding4 {
>     disable: true
>    } 
> }
> 
> policy {
>  policy-statement export-connected {
>  term 100 {
>  from {
>   protocol:"connected"
>   network4: 172.16.0.0/24      
>       }
>  to   { 
>   neighbor: 172.16.1.0
>       }
> 
>  then { 
>   nexthop4: 172.16.1.0
>   accept
>  }
> }
> }
> }
> 
> protocols {
>     bgp {
>  bgp-id: 172.16.0.0
>  local-as: 33333
>  export: "export-connected" 
> 
>  peer 172.16.1.0 {
>      local-ip: 172.16.0.0
>      as: 33334
>      next-hop: 172.16.1.0
> 
>      local-port: 179
>      peer-port: 179
>      holdtime: 120
>      
>  }
>  
>  peer 172.16.2.0 {
>      local-ip: 172.16.0.0
>      as: 33335
>      next-hop: 172.16.2.0
> 
>      local-port: 179
>      peer-port: 179
>      holdtime: 120
> 
>  }
> 
>  peer 172.16.3.0 {
>      local-ip: 172.16.0.1
>      as: 33336
>      next-hop: 172.16.3.0
>      local-port: 179
>      peer-port: 179
>      holdtime: 120
> 
>      ipv4-unicast: true
>      
>      
>  } 
> 
>  
>     }
> }
> 
> Here is my BGP output.
> 
> root at debian> show bgp routes
> Status Codes: * valid route, > best route
> Origin Codes: i IGP, e EGP, ? incomplete
> 
> Prefix             Nexthop     Peer       AS Path
> *> 172.16.0.0/24  172.16.0.0  0.0.0.0        i
> 
> The output look something wrong to me though.
> Can anyone help me solve this problem.Thanks.
> 
>        
> ---------------------------------
> Never miss a thing.   Make Yahoo your homepage._______________________________________________
> Xorp-users mailing list
> Xorp-users at xorp.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users


From amaizuddin at yahoo.com  Wed Mar 26 22:46:05 2008
From: amaizuddin at yahoo.com (aizuddin ariffin)
Date: Wed, 26 Mar 2008 22:46:05 -0700 (PDT)
Subject: [Xorp-users] BGP route
In-Reply-To: <mailman.15.1206471620.7299.xorp-users@xorp.org>
Message-ID: <796592.69483.qm@web90302.mail.mud.yahoo.com>

Thanks for the interface advice.Then about the output
of show bgp route.Why the peer is 0.0.0.0 and AS path
is not 33333 as I configured before.Could you show me
the right way to configure it.

Thanks.
----------------------------------------------------------------------
> 
> Message: 1
> Date: Tue, 25 Mar 2008 10:41:07 -0700 (PDT)
> From: aizuddin ariffin <amaizuddin at yahoo.com>
> Subject: [Xorp-users] BGP route
> To: xorp-users at xorp.org
> Message-ID:
> <275830.90421.qm at web90301.mail.mud.yahoo.com>
> Content-Type: text/plain; charset="iso-8859-1"
> 
> 
> Hi all.Can anyone help me check my BGP
> configuration?
> Here is my configuration.This is my first time using
> XORP and hope anyone can help me.
> Thanks.
> 
> interfaces {
>     interface eth0 {
>  description: "data interface"
>  vif eth0 {
>      address 172.16.0.0 {
>   prefix-length: 24
>   broadcast: 172.16.0.255
>      }
>  }
>     }
> }
> 
> fea {
>     unicast-forwarding4 {
>     disable: true
>    } 
> }
> 
> policy {
>  policy-statement export-connected {
>  term 100 {
>  from {
>   protocol:"connected"
>   network4: 172.16.0.0/24      
>       }
>  to   { 
>   neighbor: 172.16.1.0
>       }
> 
>  then { 
>   nexthop4: 172.16.1.0
>   accept
>  }
> }
> }
> }
> 
> protocols {
>     bgp {
>  bgp-id: 172.16.0.0
>  local-as: 33333
>  export: "export-connected" 
> 
>  peer 172.16.1.0 {
>      local-ip: 172.16.0.0
>      as: 33334
>      next-hop: 172.16.1.0
> 
>      local-port: 179
>      peer-port: 179
>      holdtime: 120
>      
>  }
>  
>  peer 172.16.2.0 {
>      local-ip: 172.16.0.0
>      as: 33335
>      next-hop: 172.16.2.0
> 
>      local-port: 179
>      peer-port: 179
>      holdtime: 120
> 
>  }
> 
>  peer 172.16.3.0 {
>      local-ip: 172.16.0.1
>      as: 33336
>      next-hop: 172.16.3.0
>      local-port: 179
>      peer-port: 179
>      holdtime: 120
> 
>      ipv4-unicast: true
>      
>      
>  } 
> 
>  
>     }
> }
> 
> Here is my BGP output.
> 
> root at debian> show bgp routes
> Status Codes: * valid route, > best route
> Origin Codes: i IGP, e EGP, ? incomplete
> 
> Prefix             Nexthop     Peer       AS Path
> *> 172.16.0.0/24  172.16.0.0  0.0.0.0        i
> 
> The output look something wrong to me though.
> Can anyone help me solve this problem.Thanks.
> 
>        
> ---------------------------------
> Never miss a thing.   Make Yahoo your homepage.
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
>
http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20080325/c125dc34/attachment-0001.html
> 
> 
> ------------------------------
> 
> Message: 2
> Date: Tue, 25 Mar 2008 11:05:01 -0700
> From: Atanu Ghosh <atanu at ICSI.Berkeley.EDU>
> Subject: Re: [Xorp-users] BGP route
> To: aizuddin ariffin <amaizuddin at yahoo.com>
> Cc: xorp-users at xorp.org
> Message-ID: <59130.1206468301 at tigger.icir.org>
> 
> Hi,
> 
> The output of "show bgp routes" looks fine assuming
> that you have not
> formed any peerings, or that the peers are not
> sending any routes.
> 
>        Atanu.
> 
> >>>>> "aizuddin" == aizuddin ariffin
> <amaizuddin at yahoo.com> writes:
> 
>     aizuddin> Hi all.Can anyone help me check my BGP
> configuration?
>     aizuddin> Here is my configuration.This is my
> first time using
>     aizuddin> XORP and hope anyone can help me.
>     aizuddin> Thanks.
>     aizuddin> interfaces {
>     aizuddin> interface eth0 {
>     aizuddin> description: "data interface"
>     aizuddin> vif eth0 {
>     aizuddin> address 172.16.0.0 {
>     aizuddin> prefix-length: 24
>     aizuddin> broadcast: 172.16.0.255
>     aizuddin> }
>     aizuddin> }
>     aizuddin> }
>     aizuddin> }
>     aizuddin> fea {
>     aizuddin> unicast-forwarding4 {
>     aizuddin> disable: true
>     aizuddin> } 
>     aizuddin> }
>     aizuddin> policy {
>     aizuddin> policy-statement export-connected {
>     aizuddin> term 100 {
>     aizuddin> from {
>     aizuddin> protocol:"connected"
>     aizuddin> network4: 172.16.0.0/24      
>     aizuddin> }
>     aizuddin> to   { 
>     aizuddin> neighbor: 172.16.1.0
>     aizuddin> }
> 
=== message truncated ===



      ____________________________________________________________________________________
Never miss a thing.  Make Yahoo your home page. 
http://www.yahoo.com/r/hs


From atanu at ICSI.Berkeley.EDU  Wed Mar 26 22:59:19 2008
From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh)
Date: Wed, 26 Mar 2008 22:59:19 -0700
Subject: [Xorp-users] BGP route
In-Reply-To: Message from aizuddin ariffin <amaizuddin@yahoo.com> of "Wed,
	26 Mar 2008 22:46:05 PDT."
	<796592.69483.qm@web90302.mail.mud.yahoo.com> 
Message-ID: <19251.1206597559@tigger.icir.org>

Hi,

Routes that are introduced via policy come via the internal peer
0.0.0.0. The route will have the AS number of the router added to AS
path when the route is sent to a peer.

     Atanu.

>>>>> "aizuddin" == aizuddin ariffin <amaizuddin at yahoo.com> writes:

    aizuddin> Thanks for the interface advice.Then about the output
    aizuddin> of show bgp route.Why the peer is 0.0.0.0 and AS path
    aizuddin> is not 33333 as I configured before.Could you show me
    aizuddin> the right way to configure it.

    aizuddin> Thanks.
    aizuddin> ----------------------------------------------------------------------
    >> 
    >> Message: 1
    >> Date: Tue, 25 Mar 2008 10:41:07 -0700 (PDT)
    >> From: aizuddin ariffin <amaizuddin at yahoo.com>
    >> Subject: [Xorp-users] BGP route
    >> To: xorp-users at xorp.org
    >> Message-ID:
    >> <275830.90421.qm at web90301.mail.mud.yahoo.com>
    >> Content-Type: text/plain; charset="iso-8859-1"
    >> 
    >> 
    >> Hi all.Can anyone help me check my BGP
    >> configuration?
    >> Here is my configuration.This is my first time using
    >> XORP and hope anyone can help me.
    >> Thanks.
    >> 
    >> interfaces {
    >> interface eth0 {
    >> description: "data interface"
    >> vif eth0 {
    >> address 172.16.0.0 {
    >> prefix-length: 24
    >> broadcast: 172.16.0.255
    >> }
    >> }
    >> }
    >> }
    >> 
    >> fea {
    >> unicast-forwarding4 {
    >> disable: true
    >> } 
    >> }
    >> 
    >> policy {
    >> policy-statement export-connected {
    >> term 100 {
    >> from {
    >> protocol:"connected"
    >> network4: 172.16.0.0/24      
    >> }
    >> to   { 
    >> neighbor: 172.16.1.0
    >> }
    >> 
    >> then { 
    >> nexthop4: 172.16.1.0
    >> accept
    >> }
    >> }
    >> }
    >> }
    >> 
    >> protocols {
    >> bgp {
    >> bgp-id: 172.16.0.0
    >> local-as: 33333
    >> export: "export-connected" 
    >> 
    >> peer 172.16.1.0 {
    >> local-ip: 172.16.0.0
    >> as: 33334
    >> next-hop: 172.16.1.0
    >> 
    >> local-port: 179
    >> peer-port: 179
    >> holdtime: 120
    >> 
    >> }
    >> 
    >> peer 172.16.2.0 {
    >> local-ip: 172.16.0.0
    >> as: 33335
    >> next-hop: 172.16.2.0
    >> 
    >> local-port: 179
    >> peer-port: 179
    >> holdtime: 120
    >> 
    >> }
    >> 
    >> peer 172.16.3.0 {
    >> local-ip: 172.16.0.1
    >> as: 33336
    >> next-hop: 172.16.3.0
    >> local-port: 179
    >> peer-port: 179
    >> holdtime: 120
    >> 
    >> ipv4-unicast: true
    >> 
    >> 
    >> } 
    >> 
    >> 
    >> }
    >> }
    >> 
    >> Here is my BGP output.
    >> 
    >> root at debian> show bgp routes
    >> Status Codes: * valid route, > best route
    >> Origin Codes: i IGP, e EGP, ? incomplete
    >> 
    >> Prefix             Nexthop     Peer       AS Path
    >> *> 172.16.0.0/24  172.16.0.0  0.0.0.0        i
    >> 
    >> The output look something wrong to me though.
    >> Can anyone help me solve this problem.Thanks.
    >> 
    >> 
    >> ---------------------------------
    >> Never miss a thing.   Make Yahoo your homepage.
    >> -------------- next part --------------
    >> An HTML attachment was scrubbed...
    >> URL:
    >> 
    aizuddin> http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20080325/c125dc34/attachment-0001.html
    >> 
    >> 
    >> ------------------------------
    >> 
    >> Message: 2
    >> Date: Tue, 25 Mar 2008 11:05:01 -0700
    >> From: Atanu Ghosh <atanu at ICSI.Berkeley.EDU>
    >> Subject: Re: [Xorp-users] BGP route
    >> To: aizuddin ariffin <amaizuddin at yahoo.com>
    >> Cc: xorp-users at xorp.org
    >> Message-ID: <59130.1206468301 at tigger.icir.org>
    >> 
    >> Hi,
    >> 
    >> The output of "show bgp routes" looks fine assuming
    >> that you have not
    >> formed any peerings, or that the peers are not
    >> sending any routes.
    >> 
    >> Atanu.
    >> 
    >> >>>>> "aizuddin" == aizuddin ariffin
    >> <amaizuddin at yahoo.com> writes:
    >> 
    aizuddin> Hi all.Can anyone help me check my BGP
    >> configuration?
    aizuddin> Here is my configuration.This is my
    >> first time using
    aizuddin> XORP and hope anyone can help me.
    aizuddin> Thanks.
    aizuddin> interfaces {
    aizuddin> interface eth0 {
    aizuddin> description: "data interface"
    aizuddin> vif eth0 {
    aizuddin> address 172.16.0.0 {
    aizuddin> prefix-length: 24
    aizuddin> broadcast: 172.16.0.255
    aizuddin> }
    aizuddin> }
    aizuddin> }
    aizuddin> }
    aizuddin> fea {
    aizuddin> unicast-forwarding4 {
    aizuddin> disable: true
    aizuddin> } 
    aizuddin> }
    aizuddin> policy {
    aizuddin> policy-statement export-connected {
    aizuddin> term 100 {
    aizuddin> from {
    aizuddin> protocol:"connected"
    aizuddin> network4: 172.16.0.0/24      
    aizuddin> }
    aizuddin> to   { 
    aizuddin> neighbor: 172.16.1.0
    aizuddin> }
    >> 
    aizuddin> === message truncated ===



    aizuddin> ____________________________________________________________________________________
    aizuddin> Never miss a thing.  Make Yahoo your home page. 
    aizuddin> http://www.yahoo.com/r/hs

    aizuddin> _______________________________________________
    aizuddin> Xorp-users mailing list
    aizuddin> Xorp-users at xorp.org
    aizuddin> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users


From yueli.m at gmail.com  Thu Mar 27 21:39:34 2008
From: yueli.m at gmail.com (Yue Li)
Date: Fri, 28 Mar 2008 00:39:34 -0400
Subject: [Xorp-users] Routes redistribution between OSPF and BGP
In-Reply-To: <51243.1206375649@tigger.icir.org>
References: <yueli.m@gmail.com>
	<49567c360803172108j6f728e5ds4423fe7eda633808@mail.gmail.com>
	<51243.1206375649@tigger.icir.org>
Message-ID: <49567c360803272139k5244b0ds4df50a14f5218e54@mail.gmail.com>

Hi, Atanu
I have a topology like below. I run OSPF on all routers and BGP on R2,
R5, which forms a eBGP peering.

The problem is when I redistribute OSPF into BGP, I can only see the
routes to "net13" and "net34" on R5.
I wonder whether I should export "connected" to BGP, so I may see
"net12" and "net24" on R5.

              net12
         (R1)---------(R2)------------(R5)----------(R6)
 net13  |              |                  |                |
           |    AS1    | net24         |     AS2    |
         (R3)---------(R4)             (R7)-----------(R8)
                net34

The config of R2 is:
interfaces {
   interface tun0 {
       disable: false
       vif tun0 {
          disable: false
          address 10.0.0.1 {
             prefix-length: 30
                disable: false
          }
       }
   }
   interface tun1 {
       disable: false
       vif tun1 {
          disable: false
          address 10.0.0.17 {
             prefix-length: 30
                disable: false
          }
       }
   }
   interface tun2 {
       disable: false
       vif tun2 {
          disable: false
          address 10.0.0.65 {
             prefix-length: 30
                disable: false
          }
       }
   }
}
policy {
  policy-statement connected {
    term export {
        from {
             protocol: "connected"
        }
    }
 }
  policy-statement ospf-to-bgp {
    term ospf2bgp {
        from {
             protocol: "ospf4"
        }
    }
 }
}
protocols {
  ospf4 {
     router-id: 10.0.0.1
     export: "connected"
     area 0.0.0.0 {
       interface tun0 {
           link-type: "p2p"
           vif tun0 {
              address 10.0.0.1 {
                 hello-interval: 10
                 interface-cost: 100
                 neighbor 10.0.0.2 {
                     router-id: 10.0.0.2
                 }
              }
           }
        }
       interface tun1 {
           link-type: "p2p"
           vif tun1 {
              address 10.0.0.17 {
                 hello-interval: 10
                 interface-cost: 100
                 neighbor 10.0.0.18 {
                     router-id: 10.0.0.14
                 }
              }
           }
        }
     }
   }
   bgp {
      bgp-id: 10.0.0.1
      export: "ospf-to-bgp"
      local-as: 65010
      peer 10.0.0.66 {
          local-ip: 10.0.0.65
          as: 65011
          next-hop: 10.0.0.65
          ipv4-multicast: false
          ipv6-unicast: false
          ipv6-multicast: false
      }
   }
}



On Mon, Mar 24, 2008 at 12:20 PM, Atanu Ghosh <atanu at icsi.berkeley.edu> wrote:
> Hi,
>
>  All the networks that you wish to advertise to an external AS need to be
>  redistributed into BGP. You therefore need to redistribute OSPF into
>  BGP.
>
>         Atanu.
>
>  >>>>> "Yue" == Yue Li <yueli.m at gmail.com> writes:
>
>     Yue> Hi, All I have several XORP routers which form 2 Autonomous
>     Yue> Systems.  OSPFv2 is used for intra-AS protocol and BGP is
>     Yue> running on the AS border routers.
>
>     Yue> I found no BGP routes when monitoring BGP behaviors, while
>     Yue> their peering relations are correct.  And routers in different
>     Yue> AS can't ping each other.
>
>     Yue> So I guess I need to add routes redistribution to the
>     Yue> configuration of the AS border routers, right?  Do I need to
>     Yue> add ospf-to-bgp policy, or bgp-to-ospf policy, or both of them?
>
>     Yue> Any help would be greatly appreciated.
>
>     Yue> _______________________________________________ Xorp-users
>     Yue> mailing list Xorp-users at xorp.org
>     Yue> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users
>


From atanu at ICSI.Berkeley.EDU  Mon Mar 31 19:15:16 2008
From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh)
Date: Mon, 31 Mar 2008 19:15:16 -0700
Subject: [Xorp-users] Routes redistribution between OSPF and BGP
In-Reply-To: Message from "Yue Li" <yueli.m@gmail.com> of "Fri,
	28 Mar 2008 00:39:34 EDT."
	<49567c360803272139k5244b0ds4df50a14f5218e54@mail.gmail.com> 
Message-ID: <82941.1207016116@tigger.icir.org>

Hi,

When redistributing routes from OSPF to BGP only the routes that OSPF
has learned from its neighbours will be redistributed. The connected
routes will not be redistributed, so you are correct you also need to
redistribute connected.

       Atanu.

>>>>> "Yue" == Yue Li <yueli.m at gmail.com> writes:

    Yue> Hi, Atanu
    Yue> I have a topology like below. I run OSPF on all routers and BGP on R2,
    Yue> R5, which forms a eBGP peering.

    Yue> The problem is when I redistribute OSPF into BGP, I can only see the
    Yue> routes to "net13" and "net34" on R5.
    Yue> I wonder whether I should export "connected" to BGP, so I may see
    Yue> "net12" and "net24" on R5.

    Yue> net12
    Yue> (R1)---------(R2)------------(R5)----------(R6)
    Yue> net13  |              |                  |                |
    Yue> |    AS1    | net24         |     AS2    |
    Yue> (R3)---------(R4)             (R7)-----------(R8)
    Yue> net34

    Yue> The config of R2 is:
    Yue> interfaces {
    Yue> interface tun0 {
    Yue> disable: false
    Yue> vif tun0 {
    Yue> disable: false
    Yue> address 10.0.0.1 {
    Yue> prefix-length: 30
    Yue> disable: false
    Yue> }
    Yue> }
    Yue> }
    Yue> interface tun1 {
    Yue> disable: false
    Yue> vif tun1 {
    Yue> disable: false
    Yue> address 10.0.0.17 {
    Yue> prefix-length: 30
    Yue> disable: false
    Yue> }
    Yue> }
    Yue> }
    Yue> interface tun2 {
    Yue> disable: false
    Yue> vif tun2 {
    Yue> disable: false
    Yue> address 10.0.0.65 {
    Yue> prefix-length: 30
    Yue> disable: false
    Yue> }
    Yue> }
    Yue> }
    Yue> }
    Yue> policy {
    Yue> policy-statement connected {
    Yue> term export {
    Yue> from {
    Yue> protocol: "connected"
    Yue> }
    Yue> }
    Yue> }
    Yue> policy-statement ospf-to-bgp {
    Yue> term ospf2bgp {
    Yue> from {
    Yue> protocol: "ospf4"
    Yue> }
    Yue> }
    Yue> }
    Yue> }
    Yue> protocols {
    Yue> ospf4 {
    Yue> router-id: 10.0.0.1
    Yue> export: "connected"
    Yue> area 0.0.0.0 {
    Yue> interface tun0 {
    Yue> link-type: "p2p"
    Yue> vif tun0 {
    Yue> address 10.0.0.1 {
    Yue> hello-interval: 10
    Yue> interface-cost: 100
    Yue> neighbor 10.0.0.2 {
    Yue> router-id: 10.0.0.2
    Yue> }
    Yue> }
    Yue> }
    Yue> }
    Yue> interface tun1 {
    Yue> link-type: "p2p"
    Yue> vif tun1 {
    Yue> address 10.0.0.17 {
    Yue> hello-interval: 10
    Yue> interface-cost: 100
    Yue> neighbor 10.0.0.18 {
    Yue> router-id: 10.0.0.14
    Yue> }
    Yue> }
    Yue> }
    Yue> }
    Yue> }
    Yue> }
    Yue> bgp {
    Yue> bgp-id: 10.0.0.1
    Yue> export: "ospf-to-bgp"
    Yue> local-as: 65010
    Yue> peer 10.0.0.66 {
    Yue> local-ip: 10.0.0.65
    Yue> as: 65011
    Yue> next-hop: 10.0.0.65
    Yue> ipv4-multicast: false
    Yue> ipv6-unicast: false
    Yue> ipv6-multicast: false
    Yue> }
    Yue> }
    Yue> }



    Yue> On Mon, Mar 24, 2008 at 12:20 PM, Atanu Ghosh <atanu at icsi.berkeley.edu> wrote:
    >> Hi,
    >> 
    >> All the networks that you wish to advertise to an external AS need to be
    >> redistributed into BGP. You therefore need to redistribute OSPF into
    >> BGP.
    >> 
    >> Atanu.
    >> 
    >> >>>>> "Yue" == Yue Li <yueli.m at gmail.com> writes:
    >> 
    Yue> Hi, All I have several XORP routers which form 2 Autonomous
    Yue> Systems.  OSPFv2 is used for intra-AS protocol and BGP is
    Yue> running on the AS border routers.
    >> 
    Yue> I found no BGP routes when monitoring BGP behaviors, while
    Yue> their peering relations are correct.  And routers in different
    Yue> AS can't ping each other.
    >> 
    Yue> So I guess I need to add routes redistribution to the
    Yue> configuration of the AS border routers, right?  Do I need to
    Yue> add ospf-to-bgp policy, or bgp-to-ospf policy, or both of them?
    >> 
    Yue> Any help would be greatly appreciated.
    >> 
    Yue> _______________________________________________ Xorp-users
    Yue> mailing list Xorp-users at xorp.org
    Yue> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users
    >>