I have some catalysts switches and need to tune one of them (switch A) for following environment. Switch A has 2 vrfs, one to connect to other catalysts (vpn_rt) and one to route local subnets (vpn_common). Route leaking is made by bgp.
vpn_common contains one subnet, 192.168.59.0/24. vpn_rt has route to this subnet:
sh ip route vrf vpn_rt | b 59 192.168.59.0/24 is variably subnetted, 2 subnets, 2 masks B 192.168.59.0/24 is directly connected (vpn_common), 1d00h, Vlan59 L 192.168.59.1/32 is directly connected, Vlan59
I want catalyst A to tell another catalyst that 192.168.59.0/24 is available via A, but I have no idea how do I redistribute L-type route. Any help is appreciated.
I dont have concrete update on this, but sharing my initial analysis. Router is not advertising with RD of vrf CUST-B, though route is there is bgp vpnv4 table. Now to resolve your issue, would like to understand your design. Why we are using two vrf? is it mandatory that we advertise prefix from second vrf (vpn_rt). Can not we advertise route directly from vpn_common.
I tried to configure two vrf on a router CUST-A and CUST-B.
\ PE1 ----mbgp--------------PE2
CE2 ----184.108.40.206/24---vrf CUST-B
when we do vrf leaking by importing RT of CUST-A on vrf CUST-B on PE1, we see below two routes in vpnv4 bgp table
R3#show ip b vpnv4 all 10.10.10.0/24 BGP routing table entry for 300:1:10.10.10.0/24, version 5 Paths: (1 available, best #1, table CUST-A) Advertised to update-groups: 1 5 Local 0.0.0.0 from 0.0.0.0 (220.127.116.11) Origin incomplete, metric 0, localpref 100, weight 32768, valid, sourced, best Extended Community: RT:300:1 mpls labels in/out 31/nolabel(CUST-A) BGP routing table entry for 300:2:10.10.10.0/24, version 6 Paths: (1 available, best #1, table CUST-B) Not advertised to any peer Local, imported path from 300:1:10.10.10.0/24 <<<<< this is imported from RD 300:1 0.0.0.0 (via CUST-A) from 0.0.0.0 (18.104.22.168) Origin incomplete, metric 0, localpref 100, weight 32768, valid, external, best Extended Community: RT:300:1 mpls labels in/out nolabel/nolabel(CUST-B) R3#
So we have routes in vpnv4 bgp table with RD 300:2 (vrf cust-B) but it is not being advertised as locally imported
Ran debug bgp vpnv4 uni updates and see that route with RD 300:2 is skipped
BGP: TX VPNv4 Unicast Wkr global 4 Cur Processing. BGP: TX VPNv4 Unicast Wkr global 4 Cur Attr change from 0x0 to 0x508E514. BGP: TX VPNv4 Unicast Rpl global 4 1 Net 300:1:10.10.10.0/24 Set advertised bit (total 1). BGP: TX VPNv4 Unicast Wkr global 4 Cur Net 300:1:10.10.10.0/24 Formatted. BGP: TX VPNv4 Unicast Wkr global 4 Cur Net 300:2:10.10.10.0/24 Skipped. <<< BGP: TX VPNv4 Unicast Wkr global 4 Cur Replicating. BGP: TX VPNv4 Unicast Wkr global 4 Cur Suspending (attr change), processed 1 attr(s), 1/2 net(s), 0 pos.
Every catalyst used has some vrfs for customers subnets - different customers need different gateway. Interfaces connecting catalysts are using another vrf. Routes between vrfs are exchanged using BGP.
Every catalyst has a routing interface within same vlan - vlan20 (192.168.20.0/24), links between catalists are trunks (vlan20 is allowed at trunks mentioned). OSPF proccess is running for 192.168.20.0/24 (it's backbone area). One separate router advertises static routes for every OSPF user.
Currently redundancy (more links between catalysts) is served by MSTP. And we have big broadcast domain spanning whole enterprise (vlan20).
I am planning to change trunks between catalysts to separate routing interfaces and change MSTP-redundancy to some routing redundant features, but i've got a problem - catalyst should advertise route to his subnet by himself. Otherwise if advertising is made by separate router (current situation) I should advertise two routes at the same time and if one route fails no one has an idea about it. And I stumbled upon it - catalyst doesnt want to advertise route he got via bgp leaking. I think i'm missing some bgp tuning because it seems to be kinda easy - force OSPF to redistribute dynamic route.
Or maybe there is some other way to advertise redundant routes.
We are pleased to announce availability of Beta software for 16.6.3. 16.6.3 will be the second rebuild on the 16.6 release train targeted towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are looking for early feedback from custome...