[Xorp-users] Fwd: Route redistribution issue
Igor Maravić
igorm at etf.rs
Fri Jul 20 07:36:06 PDT 2012
Well,
This is just as it should be.
You're exporting connected routes to rip and ospf, thus they have two tags
(0 and 2).
You're exporting ospf routes to rip, thus they have only one tag (1).
As you can see 10.0.6.0/24 (and 10.0.2.0/24) has the same tag as other OSPF
routes.
Because of that it should be redistributed the same way as other OSPF
routes.
It looks like RIP BUG to me.
Could you send me routes that you see on n2 and n9.
BR
Igor
2012/7/20 Phil Wiggins <phil.wiggins at gmail.com>
> Igor,
>
> Thanks for your persistence. I've enclosed the outputs as needed. I've
> also provided similar metric info from Quagga (n4, n5).
>
> n3 output:
> ========
> root at n3:/tmp/pycore.55456/n3.conf# xorpsh
> Welcome to XORP v1.8.6-WIP on n3
> Version tag: 00000000 Build Date: 2012-07-20 09:44 32-bit
> root at n3> show route table ipv4 unicast final
> 10.0.0.0/24 [rip(120)/1]
> > to 10.0.1.1 via eth0/eth0 TAGS 3
> 10.0.1.0/24 [connected(0)/0]
> > via eth0/eth0 TAGS 0, 2
> 10.0.2.0/24 [connected(0)/0]
> > via eth1/eth1 TAGS 0, 2
> 10.0.3.0/24 [ospf(110)/11]
> > to 10.0.2.1 via eth1/eth1 TAGS 1
> 10.0.6.0/24 [ospf(110)/21]
> > to 10.0.2.1 via eth1/eth1 TAGS 1
> 10.0.7.0/24 [ospf(110)/1]
> > to 10.0.2.1 via eth1/eth1 TAGS 1
> 10.0.8.0/24 [ospf(110)/1]
> > to 10.0.2.1 via eth1/eth1 TAGS 1
> root at n3>
>
> n8 output:
> =======
> root at n8:/tmp/pycore.55456/n8.conf# xorpsh
> Welcome to XORP v1.8.6-WIP on n8
> Version tag: 00000000 Build Date: 2012-07-20 09:44 32-bit
> root at n8> show route table ipv4 unicast final
> 10.0.0.0/24 [ospf(110)/1]
> > to 10.0.6.2 via eth0/eth0 TAGS 1
> 10.0.1.0/24 [ospf(110)/1]
> > to 10.0.6.2 via eth0/eth0 TAGS 1
> 10.0.2.0/24 [ospf(110)/21]
> > to 10.0.6.2 via eth0/eth0 TAGS 1
> 10.0.3.0/24 [ospf(110)/11]
> > to 10.0.6.2 via eth0/eth0 TAGS 1
> 10.0.6.0/24 [connected(0)/0]
> > via eth0/eth0 TAGS 0, 2
> 10.0.7.0/24 [connected(0)/0]
> > via eth1/eth1 TAGS 0, 2
> 10.0.8.0/24 [rip(120)/1]
> > to 10.0.7.2 via eth1/eth1 TAGS 3
> root at n8>
>
> n4 output:
> =======
> n4# sho ip ro
> Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF,
> I - ISIS, B - BGP, > - selected route, * - FIB route
>
> O>* 10.0.0.0/24 [110/1] via 10.0.2.2, eth0, 00:04:01
> O>* 10.0.1.0/24 [110/0] via 10.0.2.2, eth0, 00:04:15
> O 10.0.2.0/24 [110/10] is directly connected, eth0, 00:04:16
> C>* 10.0.2.0/24 is directly connected, eth0
> O 10.0.3.0/24 [110/10] is directly connected, eth1, 00:05:02
> C>* 10.0.3.0/24 is directly connected, eth1
> O>* 10.0.6.0/24 [110/20] via 10.0.3.2, eth1, 00:04:12
> O>* 10.0.7.0/24 [110/0] via 10.0.3.2, eth1, 00:04:11
> O>* 10.0.8.0/24 [110/1] via 10.0.3.2, eth1, 00:04:11
> C>* 127.0.0.0/8 is directly connected, lo
> n4#
>
> n5 output:
> =======
> n5# sho ip ro
> Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF,
> I - ISIS, B - BGP, > - selected route, * - FIB route
>
> O>* 10.0.0.0/24 [110/1] via 10.0.3.1, eth0, 00:04:20
> O>* 10.0.1.0/24 [110/0] via 10.0.3.1, eth0, 00:04:30
> O>* 10.0.2.0/24 [110/20] via 10.0.3.1, eth0, 00:04:31
> O 10.0.3.0/24 [110/10] is directly connected, eth0, 00:05:31
> C>* 10.0.3.0/24 is directly connected, eth0
> O 10.0.6.0/24 [110/10] is directly connected, eth1, 00:05:31
> C>* 10.0.6.0/24 is directly connected, eth1
> O>* 10.0.7.0/24 [110/0] via 10.0.6.1, eth1, 00:04:44
> O>* 10.0.8.0/24 [110/1] via 10.0.6.1, eth1, 00:04:44
> C>* 127.0.0.0/8 is directly connected, lo
> n5#
>
>
> Phil
>
> On Fri, Jul 20, 2012 at 5:27 AM, Igor Maravić <igorm at etf.rs> wrote:
>
>> I really didn't have time to boot up your configuration with Quagga.
>> Could you apply patch that I've attached in email to n3 i n8 machines.
>> After you do that, turn on the network and send me in email what do you
>> see when you enter
>>
>> show route table ipv4 unicast final
>>
>> in xorpsh on n3 and n8. I'm interested in TAG field, which I added via
>> patch that I've attached.
>> BR
>> Igor
>>
>>
>> 2012/7/17 Phil Wiggins <phil.wiggins at gmail.com>
>>
>>> Igor,
>>>
>>> Thanks for looking into this issue. I've also attached a CORE4.3 imn
>>> file, if that helps. Once the network converges, the subnet at
>>> 10.0.6.0/24 isn't visible to nodes n1 and n2. Similarly, the subnet at
>>> 10.0.2.0/24 isn't visible to nodes n9 and n10.
>>>
>>> Here are the config.boots for n3 and n8, slightly cleaned up from the
>>> previous post:
>>>
>>> n3:config.boot
>>> ==============
>>> interfaces {
>>> interface eth0 {
>>> vif eth0 {
>>> address 10.0.1.2 {
>>> prefix-length: 24
>>> }
>>> }
>>> }
>>> interface eth1 {
>>> vif eth1 {
>>> address 10.0.2.2 {
>>> prefix-length: 24
>>> }
>>> }
>>> }
>>> }
>>>
>>> fea {
>>> unicast-forwarding4 {
>>> disable:false
>>> }
>>> }
>>>
>>> protocols {
>>> rip {
>>> export: "connected-to-rip,ospf4-to-rip"
>>> interface eth0 {
>>> vif eth0 {
>>> address 10.0.1.2 {
>>> disable: false
>>> }
>>> }
>>> }
>>> }
>>> ospf4 {
>>> export: "connected-to-ospf4,rip-to-ospf4"
>>> router-id: 10.0.2.2
>>> area 0.0.0.0 {
>>> interface eth1 {
>>> vif eth1 {
>>> address 10.0.2.2 {
>>> }
>>> }
>>> }
>>> }
>>> }
>>> }
>>>
>>> policy {
>>> policy-statement connected-to-rip {
>>> term 100 {
>>> from {
>>> protocol: "connected"
>>> }
>>> then {
>>> metric: 1
>>> accept
>>> }
>>> }
>>> }
>>> policy-statement connected-to-ospf4 {
>>> term 200 {
>>> from {
>>> protocol: "connected"
>>> }
>>> then {
>>> accept
>>> }
>>> }
>>> }
>>> policy-statement rip-to-ospf4 {
>>> term 300 {
>>> from {
>>> protocol: "rip"
>>> }
>>> then {
>>> metric add 0
>>> accept
>>> }
>>> }
>>> }
>>> policy-statement ospf4-to-rip {
>>> term 400 {
>>> from {
>>> protocol: "ospf4"
>>> }
>>> then {
>>> metric add 0
>>> accept
>>> }
>>> }
>>> }
>>> }
>>> n8:config.boot
>>> ==============
>>> interfaces {
>>> interface eth0 {
>>> vif eth0 {
>>> address 10.0.6.1 {
>>> prefix-length: 24
>>> }
>>> }
>>> }
>>> interface eth1 {
>>> vif eth1 {
>>> address 10.0.7.1 {
>>> prefix-length: 24
>>> }
>>> }
>>> }
>>> }
>>>
>>> fea {
>>> unicast-forwarding4 {
>>> disable:false
>>> }
>>> }
>>>
>>> protocols {
>>> ospf4 {
>>> export: "connected-to-ospf4,rip-to-ospf4"
>>> router-id: 10.0.6.1
>>> area 0.0.0.0 {
>>> interface eth0 {
>>> vif eth0 {
>>> address 10.0.6.1 {
>>> disable: false
>>> }
>>> }
>>> }
>>> }
>>> }
>>> rip {
>>> export: "connected-to-rip,ospf4-to-rip"
>>> interface eth1 {
>>> vif eth1 {
>>> address 10.0.7.1 {
>>> disable: false
>>> }
>>> }
>>> }
>>> }
>>> }
>>>
>>> policy {
>>> policy-statement connected-to-rip {
>>> term 100 {
>>> from {
>>> protocol: "connected"
>>> }
>>> then {
>>> metric: 1
>>> accept
>>> }
>>> }
>>> }
>>> policy-statement connected-to-ospf4 {
>>> term 200 {
>>> from {
>>> protocol: "connected"
>>> }
>>> then {
>>> accept
>>> }
>>> }
>>> }
>>> policy-statement rip-to-ospf4 {
>>> term 300 {
>>> from {
>>> protocol: "rip"
>>> }
>>> then {
>>> metric add 0
>>> accept
>>> }
>>> }
>>> }
>>> policy-statement ospf4-to-rip {
>>> term 400 {
>>> from {
>>> protocol: "ospf4"
>>> }
>>> then {
>>> metric add 0
>>> accept
>>> }
>>> }
>>> }
>>> }
>>>
>>> Phil
>>>
>>>
>>> On Tue, Jul 17, 2012 at 6:39 PM, Igor Maravić <igorm at etf.rs> wrote:
>>>
>>>> Phil,
>>>> Could You send whole configuration file for n3 and n8. If I understood
>>>> correctly, problem is that connected route 10.0.2.0/24 and 10.0.6.0/24aren't redistributed in RIP.
>>>> I'll try it to look at the problem as soon as I find some time.
>>>> BR
>>>> Igor
>>>>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20120720/62b324a4/attachment-0001.html
More information about the Xorp-users
mailing list