If someone cares. Yes, as I suspected, the issue turned out to be pretty simple. This was my failure to grasp that NetIron does not readvertise static and connected routes from VRFs to MP-BGP by default.
So what I was missing is the following: address-family ipv4 unicast vrf l3vpn-cust-321 > redistribute connected > redistribute static > exit-address-family > Same story (which is a bit more obvious) with OSPF, for those who like it as a CE-PE protocol. Or add a BGP neighbor here for CE-PE BGP exchange and than, of course, CE-PE BGP <-> core MP-BGP readvertisement will happen automatically for a given VRF. Also (what made me feel truly stuck) NetIron does not care of VPN routes received from the core until you configure "address-family ipv4 unicast vrf <vrf-name>" stanza in the "router bgp" config. Does not even show it has received the routes (except in debug and in the count of Update messages for a neighbor). Well, to be honest, it seems to be a bit strange place in config for such an option, especially for redistribution of static and connected, since this really looks like a place having to do with only CE-PE BGP exchange. 2013/3/6 Pavel Lunin wrote: > > Hi, > > I'm a bit stuck with a pretty simple L3VPN lab config on CER2024. > > I mostly work with Juniper and haven't configured MPLS stuff on Brocade > for edges. Though I have, but a couple of years ago :) > > I just needed a basic lab setup to test a couple of things (not the L3VPN > itself) and it turned out I can't even get it up. I see the router receives > an update from neighbor but doesn't show anything about it. Just silently > ignores it. Moreover it does not advertise and vpn routes. > > I even thought it could be a license issue, but the box has advanced > premium license, and I have checked some other MPLS stuff covered with the > license (Martini VLL) and it works just fine. > > [email protected]#sho version | i Lic > License: ADV_SVCS_PREM (LID: rXXXXXXXX) > > > Could someone bother to skim through my output and check whether I miss > something really simple or it rather seem to be a software issue and should > be escalated to Brocade TAC. > > BTW I tried IronWare 5.3.0c, 5.4.0a and 5.4.0b. So it seems pretty > unrealistic that such basic a showstopper bug can exist in three releases. > > Here are some configs and diagnostics. Sorry, I know it's a bit too long > for the list :) > > VRF: > > [email protected]#sho run | beg l3vpn > vrf l3vpn-cust-321 > rd 65500:321 > route-target export 65500:321 > route-target import 65500:321 > address-family ipv4 > route-target export 65500:321 > route-target import 65500:321 > ip route 10.3.33.0/24 10.3.21.2 > exit-address-family > exit-vrf > > > CE facing iface: > > [email protected]#sho run interface ve 32 > interface ve 32 > vrf forwarding l3vpn-cust-321 > ip address 10.3.21.1/24 > ! > > BTW, CE-PE link is OK, pingable etc. > > [email protected]#sho ip vrf l3vpn-cust-321 > VRF l3vpn-cust-321, default RD 65500:321, Table ID 2 > Label: 500001, Label-Switched Mode: OFF > IP Router-Id: 10.3.21.1 > Interfaces: > v32 > Export VPN route-target communities: > RT:65500:321 > Import VPN route-target communities: > RT:65500:321 > No import route-map > No export route-map > > Address Family IPv4 > Max Routes: 1024 > Number of Unicast Routes: 2 > Export VPN route-target communities: > RT:65500:321 > Import VPN route-target communities: > RT:65500:321 > [email protected]# > > [email protected]#sho ip route vrf l3vpn-cust-321 > Total number of IP routes: 2 > Type Codes - B:BGP D:Connected I:ISIS O:OSPF R:RIP S:Static; Cost - > Dist/Metric > BGP Codes - i:iBGP e:eBGP > ISIS Codes - L1:Level-1 L2:Level-2 > OSPF Codes - i:Inter Area 1:External Type 1 2:External Type 2 s:Sham Link > Destination Gateway Port Cost > Type Uptime > 1 10.3.21.0/24 DIRECT ve 32 0/0 > D 1d1h > 2 10.3.33.0/24 10.3.21.2 ve 32 1/1 > S 1d1h > > > > BGP: > > [email protected]#show ip bgp config > Current BGP configuration: > > router bgp > local-as 65500 > capability as4 enable > neighbor 172.19.126.11 remote-as 65500 > neighbor 172.19.126.11 update-source loopback 1 > neighbor 172.19.126.11 soft-reconfiguration inbound > neighbor 172.19.126.77 remote-as 65500 > neighbor 172.19.126.77 update-source loopback 1 > neighbor 172.19.126.77 soft-reconfiguration inbound > > address-family ipv4 unicast > exit-address-family > > address-family ipv4 multicast > exit-address-family > > address-family ipv6 unicast > neighbor 172.19.126.11 activate > exit-address-family > > address-family ipv6 multicast > exit-address-family > > address-family vpnv4 unicast > neighbor 172.19.126.11 activate > neighbor 172.19.126.11 send-community both > neighbor 172.19.126.77 activate > neighbor 172.19.126.77 send-community extended > exit-address-family > > end of BGP configuration > > Both peers are JUNOS based. > > .11 is a Route Reflector, the .77 is a remote PE for this VPN. I first > started with just an RR but thought IronWare might dislike something about > Juniper's cluster ID or something and tried with a direct session. > > I see the peers advertise VPN routes and CER receives it, but: > > [email protected]#show ip bgp vpnv4 summary > BGP4 Summary > Router ID: 172.19.126.55 Local AS Number: 65500 > Confederation Identifier: not configured > Confederation Peers: > Maximum Number of IP ECMP Paths Supported for Load Sharing: 1 > Number of Neighbors Configured: 2, UP: 2 > Number of Routes Installed: 0 > Number of Routes Advertising to All Neighbors: 0 (0 entries) > Number of Attribute Entries Installed: 0 > Neighbor Address AS# State Time Rt:Accepted Filtered > Sent ToSend > 172.19.126.11 65500 ESTAB 1d 0h20m 0 0 > 0 0 > 172.19.126.77 65500 ESTAB 1d 0h20m 0 0 > 0 0 > [email protected]# > > > CER does really receive the VPN updates from the peers: > > [email protected]#show deb > Debug message destination: SSH session 1 > Debug MAC is set to: All. > IP Routing: > BGP: bgp debugging is on > BGP: updates RX debugging is on > BGP: updates TX debugging is on > BGP: route-selection debugging is on > BGP: VPNV4 Unicast Address Family debugging is on > [email protected]# > [email protected]#clear ip bg nei 172.19.126.11 > [email protected]# > [email protected]#Mar 6 13:24:43.975 BGP: BGP: 172.19.126.11 rcv UPDATE > w/attr: Origin=IGP AS_PATH= LOCAL_PREF=100 EXTENDED_COMMUNITY= RT 65500:321 > ORIGINATOR_ID=172.19.126.77 CLUSTER_LIST=0.0.255.220 > *NextHop=0:0:172.19.126.77 > * > Mar 6 13:24:43.975 BGP: (4): 172.19.126.11 rcv UPDATE Label=299936 > 65500:321:10.3.44.0/24 > Mar 6 13:24:43.975 BGP: (4): 172.19.126.11 rcv UPDATE Label=299920 > 65500:321:10.3.23.1/32 > [email protected]# > > > But no further sign of these updates: > > [email protected]#sho ip bgp vpnv4 > BGP VPNv4 Routing Table is empty > > [email protected]#sho ip bgp vpnv4 > BGP VPNv4 Routing Table is empty > > [email protected]#show ip bgp vpnv4 filtered-routes > BGP has no filtered route > > > LSP to remote PE is up and running (mpls ping is OK, Martini VLL works > across LDP LSP, etc) > > [email protected]#show mpls lsp > Note: LSPs marked with * are taking a Secondary Path > Admin Oper Tunnel Up/Dn Retry Active > Name To State State Intf Times No. Path > 55-to-11 172.19.126.11 UP UP tnl0 3 0 > -- > 55-to-33 172.19.126.33 UP UP tnl1 1 0 > -- > 55-to-77 172.19.126.77 UP UP tnl2 3 0 > -- > 55-to-99 172.19.126.99 UP UP tnl3 3 0 -- > > > [email protected]#sho mpls route 172.19.126.77 > R:RSVP L:LDP S:Static O:Others > Destination Gateway Tnnl Port Label Sig > Cost Use > 1 172.19.126.77/32 172.19.126.77 tnl2 e1/7 301216 R > 0 0 > 2 172.19.126.77/32 172.19.126.11 tnl5 e1/7 300960 L > 0 0 > > > (Also tried LDP and RSVP only config). > > Zero routes received, zero filtered, zero sent: > > [email protected]#sho ip bgp vpnv4 summary > BGP4 Summary > Router ID: 172.19.126.55 Local AS Number: 65500 > Confederation Identifier: not configured > Confederation Peers: > Maximum Number of IP ECMP Paths Supported for Load Sharing: 1 > Number of Neighbors Configured: 2, UP: 2 > Number of Routes Installed: 0 > Number of Routes Advertising to All Neighbors: 0 (0 entries) > Number of Attribute Entries Installed: 0 > Neighbor Address AS# State Time Rt:Accepted Filtered > Sent ToSend > 172.19.126.11 65500 ESTAB 0h 0m57s 0 0 > 0 0 > 172.19.126.77 65500 ESTAB 1d 0h21m 0 0 > 0 0 > > > At the same time plain IP and IPv6 routes are received through the same > iBGP sessions and work as expected: > > [email protected]#sh ip bgp > Total number of BGP Routes: 1 > Status codes: s suppressed, d damped, h history, * valid, > best, i > internal, S stale > Origin codes: i - IGP, e - EGP, ? - incomplete > Network Next Hop MED LocPrf Weight Path > *>i 0.0.0.0/0 172.19.126.11 100 0 i > > > [email protected]#sh ipv6 bgp > Total number of BGP Routes: 1 > Status codes: s suppressed, d damped, h history, * valid, > best, i > internal, S stale > Origin codes: i - IGP, e - EGP, ? - incomplete > Network Next Hop MED LocPrf Weight Path > *>i ::/0 ::ffff:172.19.126.11 > 100 0 i > > > > VRF, just in case: > > [email protected]#show ip vrf l3vpn-cust-321 > VRF l3vpn-cust-321, default RD 65500:321, Table ID 2 > Label: 500001, Label-Switched Mode: OFF > IP Router-Id: 10.3.21.1 > Interfaces: > v32 > Export VPN route-target communities: > RT:65500:321 > Import VPN route-target communities: > RT:65500:321 > No import route-map > No export route-map > > Address Family IPv4 > Max Routes: 1024 > Number of Unicast Routes: 2 > Export VPN route-target communities: > RT:65500:321 > Import VPN route-target communities: > RT:65500:321 > > > > -- > Pavel Lunin > >
_______________________________________________ foundry-nsp mailing list [email protected] http://puck.nether.net/mailman/listinfo/foundry-nsp
