[f-nsp] Route leaking/sharing behaviour?

[Piper, James]

As I mentioned previously, initially we configured local route
leaking/sharing using the standard route-target import/export
statements. Our expectation was that in a centralised services scenario
the route-targets would be imported/exported locally (as well as
remotely across MPLS). This appears not to be the case with Foundry MLX
switches, but should it be??

Our initial configuration was as follows:
 
ip vrf 1
rd 65001:1
route-target export 65001:1
route-target import 65001:3
exit-vrf
!
ip vrf 3
rd 65001:3
route-target export 65001:3
route-target import 65001:1
exit-vrf
!
interface loopback 1
ip vrf forwarding 3
ip address 192.168.3.1/24
!
interface loopback 2
ip vrf forwarding 1
ip address 192.168.4.1/24
!
interface ethernet 2/1
enable
ip vrf forwarding 3
ip address 192.168.5.1/24
!
interface ethernet 2/2
enable
ip vrf forwarding 1
ip address 192.168.6.1/24
!
router bgp
local-as 65001 
 
address-family ipv4 unicast vrf 1
redistribute connected 
exit-address-family
 
address-family ipv4 unicast vrf 3
redistribute connected 
exit-address-family
 
The expected result was:
# sh ip route vrf 1
192.168.3.1/24 (BGP)
192.168.4.1/24
192.168.5.1/24 (BGP)
192.168.6.1/24
# sh ip route vrf 3
192.168.3.1/24
192.168.4.1/24 (BGP)
192.168.5.1/24 
192.168.6.1/24 (BGP)

The observed result was:
# sh ip route vrf 1
192.168.4.1/24
192.168.6.1/24
# sh ip route vrf 3
192.168.3.1/24
192.168.5.1/24 

Do you think that the observed behaviour is what would be intuitively
expected? Would anyone else wish to use such a feature were it
implemented in a standard software release?






This e-mail and any attachments may contain confidential information that is intended solely for the use of the intended recipient and may be subject to copyright. If you receive this e-mail in error, please notify the sender immediately and delete the e-mail and its attachments from your system. You must not disclose, copy or use any part of this e-mail if you are not the intended recipient. Any opinion expressed in this e-mail and any attachments is not an opinion of RailCorp unless stated or apparent from its content. RailCorp is not responsible for any unauthorised alterations to this e-mail or any attachments. RailCorp will not incur any liability resulting directly or indirectly as a result of the recipient accessing any of the attached files that may contain a virus.