search

FRRouting / frr

The FRRouting Protocol Suite
https://frrouting.org/
Other
3.27k stars 1.24k forks source link

Is BGP MPLS 6PE still not working? #3254

Closed alemonmk closed 5 years ago

alemonmk commented 5 years ago

Things you may try first

Related Issue:

2671 #2750 #879 #421

Description

I'm trying to deploy MPLS over DMVPN and implement 6PE. I have an ISR 4321 (on dynamic IP) and a VPS as spokes and another VPS as hub, connected using OpenNHRP. MPLS is set up using targeted LDP. I then set up iBGP and tried to enable 6PE by using neighbor send-label on ISR and address-family ipv6 labeled-unicast on VPS. I can see that the labeled network advertised from ISR received FRR's bgpd but they are invalid.

Steps to Reproduce

  1. On ISR: 
    router bgp 4242421873
bgp router-id 172.22.181.1
bgp log-neighbor-changes
no bgp default ipv4-unicast
neighbor 172.22.181.2 remote-as 4242421873
neighbor 172.22.181.2 update-source Loopback0
!
address-family ipv6
redistribute ospf 1
neighbor 172.22.181.2 activate
neighbor 172.22.181.2 send-label
exit-address-family
!
  2. On VPS: 
    router bgp 4242421873
bgp router-id 172.22.181.2
bgp log-neighbor-changes
no bgp default ipv4-unicast
neighbor 172.22.181.1 remote-as 4242421873
neighbor 172.22.181.1 update-source lo1
!
address-family ipv6 labeled-unicast
neighbor 172.22.181.1 activate
exit-address-family

Expected behavior: The labeled-unicast route is valid and installed into routing table.

Actual behavior:

kotone# sh bgp ipv6 label
No BGP prefixes displayed, 0 exist

kotone# sh bgp ipv6 uni
BGP table version is 0, local router ID is 172.22.181.2, vrf id 0
Status codes:  s suppressed, d damped, h history, * valid, > best, = multipath,
               i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
Origin codes:  i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
  ifdfd:d0b7:5feb:638:acce::/80
                    ::ffff:172.22.181.1
                                            11    100      0 ?

Displayed  1 routes and 1 total paths

kotone# sh bgp ipv6 fdfd:d0b7:5feb:638:acce::/80
BGP routing table entry for fdfd:d0b7:5feb:638:acce::/80
Paths: (1 available, no best path)
  Not advertised to any peer
  Local
    ::ffff:172.22.181.1 (inaccessible) from 172.22.181.1 (172.22.181.1)
      Origin incomplete, metric 11, localpref 100, invalid, internal
      Remote label: 21
      AddPath ID: RX 0, TX 2
      Last update: Mon Oct 29 02:10:48 2018

Well, I guess the route ends up in unicast table is expected behavior...

Components

bgpd

Versions

Attachments

kotone# sh bgp ipv6 nei 172.22.181.1
...
  Neighbor capabilities:
    4 Byte AS: advertised and received
    AddPath:
      IPv6 Labeled Unicast: RX advertised IPv6 Labeled Unicast
    Route refresh: advertised and received(old & new)
    Address Family IPv4 Unicast: received
    Address Family IPv6 Unicast: received
    Address Family IPv6 Labeled Unicast: advertised and received
    Graceful Restart Capabilty: advertised and received
      Remote Restart timer is 120 seconds
      Address families by peer:
        IPv6 Labeled Unicast(not preserved)
...
 For address family: IPv6 Labeled Unicast
  Update group 1, subgroup 1
  Packet Queue length 0
  Community attribute sent to this neighbor(all)
  0 accepted prefixes
chihiro#sh bgp ipv6 nei 172.22.181.2
...
  Neighbor sessions:
    1 active, is not multisession capable (disabled)
  Neighbor capabilities:
    Route refresh: advertised and received(new)
    Four-octets ASN Capability: advertised and received
    Address family IPv6 Unicast: advertised
    ipv6 MPLS Label capability: advertised and received
    Graceful Restart Capability: advertised and received
      Remote Restart timer is 120 seconds
      Address families advertised by peer:
        none
...
 For address family: IPv6 Unicast
  Session: 172.22.181.2
  BGP table version 5, neighbor version 5/0
  Output queue size : 0
  Index 6, Advertise bit 0
  6 update-group member
  Sending Prefix & Label
  Slow-peer detection is disabled
  Slow-peer split-update-group dynamic is disabled
                                 Sent       Rcvd
  Prefix activity:               ----       ----
    Prefixes Current:               1          0
    Prefixes Total:                 1          0
    Implicit Withdraw:              0          0
    Explicit Withdraw:              0          0
    Used as bestpath:             n/a          0
    Used as multipath:            n/a          0
    Used as secondary:            n/a          0

                                   Outbound    Inbound
  Local Policy Denied Prefixes:    --------    -------
    Total:                                0          0
  Number of NLRIs in the update sent: max 2, min 0
  Last detected as dynamic slow peer: never
  Dynamic slow peer recovered: never
  Refresh Epoch: 1
  Last Sent Refresh Start-of-rib: never
  Last Sent Refresh End-of-rib: never
  Last Received Refresh Start-of-rib: never
  Last Received Refresh End-of-rib: never
                                       Sent       Rcvd
        Refresh activity:              ----       ----
          Refresh Start-of-RIB          0          0
          Refresh End-of-RIB            0          0
...
kotone# sh ip ro
Codes: K - kernel route, C - connected, S - static, R - RIP,
       O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
       T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP,
       F - PBR,
       > - selected route, * - FIB route

K>* 0.0.0.0/0 [0/0] via 139.162.122.1, eth0, 10:34:24
C>* *Public IP*/24 is directly connected, eth0, 10:34:24
O>* 172.21.79.64/28 [110/12] via 172.22.181.17, dmvpn-core, label 16, 10:26:54
O>* 172.22.181.1/32 [110/2] via 172.22.181.17, dmvpn-core, label implicit-null, 10:26:54
O   172.22.181.2/32 [110/0] is directly connected, lo, 10:34:22
C>* 172.22.181.2/32 is directly connected, lo, 10:34:24
O>* 172.22.181.3/32 [110/1] via 172.22.181.19, dmvpn-core, label implicit-null, 10:26:42
O>* 172.22.181.8/31 [110/2] via 172.22.181.17, dmvpn-core, label implicit-null, 10:26:54
O   172.22.181.16/29 [110/1] is directly connected, dmvpn-core, 10:34:16
C>* 172.22.181.16/29 is directly connected, dmvpn-core, 10:34:24
eqvinox commented 5 years ago

I'm assuming we haven't implemented crossing the address family in an MPLS setup since the v6 route needs to resolve to a label acquired by the IPv4 nexthop.

=> need to check this is indeed the case and what work is needed to get this in

adeg commented 5 years ago

I believe that the route was not being advertised because it had no local_label set. Local label should be set to implicit-null for connected, aggregated and redistributed routes. I have submitted PR #3327 which, I believe, will fix this issue.

qlyoung commented 5 years ago

3327 was merged and should be included in FRR 7.0+. Thanks for your work @adeg!