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.
