search

FRRouting / frr

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

Route-map with `set ip next-hop unchanged` not keeping original IP #3220

Closed Tuetuopay closed 5 years ago

Tuetuopay commented 6 years ago

Description

I am trying to inject type-5 routes in an L2VPN EVPN fabric using FRR as my VTEP daemon, the injector begin gobgp.

The issue is, when injecting a route, FRR will default to NOT respecting the announced gateway in the route, but use the injector's router-id. This behavior is OK as it is in line with the RFC. Yet I need to keep the announced GW IP for the NH IP, else my route injector will be getting all EVPN traffic. oops.

I tried using route-maps to turn off next-hop rewriting with the following route-map:

route-map nh-unchanged permit 10
  set ip next-hop unchanged

Here is the FRR config (similar for both VTEPs, which are 172.16.0.{1,2}):

vrf blue
  vni 1000
!
router bgp 65000 vrf blue
  bgp router-id 172.16.0.1
  address-family l2vpn evpn
    ! May not be needed, as we are injecting
    advertise ipv4 unicast
!
router bgp 65000
  bgp router-id 172.16.0.1
  neighbor 172.16.0.2 remote-as internal
  neighbor 172.16.0.5 remote-as internal
  address-family l2vpn evpn
    neighbor 172.16.0.2 activate
    neighbor 172.16.0.5 activate
    neighbor 172.16.0.5 route-map nh-unchanged in
!
route-map nh-unchanged permit 10
  set ip next-hop unchanged

Linux interfaces were setup with the following on the VTEPs (no specific Linux config on the injector):

ip link add vrf blue table 10
ip link add br1000 type bridge
ip link add vxlan1000 type vxlan id 1000 local 172.16.0.1 dstport 4789
ip link set vxlan1000 master br1000
ip link set vxlan1000 up
ip link set br1000 vrf blue
ip link set br1000 up
ip link set blue up

Here is the gobgp config:

global:
  config:
    as: 65000
    router-id: 172.16.0.5
    local-address-list:
      - 172.16.0.5
neighbors:
  - config:
      neighbor-address: 172.16.0.1
      peer-as: 65000
    afi-safis:
      - config:
          afi-safi-name: l2vpn-evpn
  - config:
      neighbor-address: 172.16.0.2
      peer-as: 65000
    afi-safis:
      - config:
          afi-safi-name: l2vpn-evpn

The route was injected using gobgp's CLI:

root@injector:~# gobgp global rib -a evpn add prefix 10.0.0.0/24 gw 172.16.0.2 etag 0 label 1000 rd 172.16.0.2:3 rt 65000:1000

(i.e. 10.0.0.0/24 via 172.16.0.2)

The two BGP daemons (FRR and gobgp) do peer and do exchange routes, and routes injected by the injector are both received and installed by FRR, but the nexthop used is the IP of the route injector, not the one of the injected route, even though the injector advertises the correct one (checked by tcpdump'ing update messages).

Steps to Reproduce

  1. Setup two machines/VMs, one with FRR, the other with gobgp
  2. Setup the Linux VRF, bridge and VXLAN interfaces
  3. Make them peer
  4. Inject the route using gobgp
  5. Check resulting route

Expected behavior: Routes are using 172.16.0.2 as the nexhop:

vtep# sh ip route vrf blue bgp'
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

VRF blue:
B>* 10.0.0.0/24 [200/0] via 172.16.0.2, br1000 onlink, 00:00:22

Actual behavior: The route-map has no effect, and the nexthop of the route is 172.16.0.5 (injector IP):

vtep# sh ip route vrf blue bgp
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

VRF blue:
B>* 10.0.0.0/24 [200/0] via 172.16.0.25, br1000 onlink, 00:00:22

vtep# sh bgp l2vpn evpn route type prefix
BGP table version is 29, local router ID is 172.16.0.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete
EVPN type-2 prefix: [2]:[EthTag]:[MAClen]:[MAC]:[IPlen]:[IP]
EVPN type-3 prefix: [3]:[EthTag]:[IPlen]:[OrigIP]
EVPN type-4 prefix: [4]:[ESI]:[IPlen]:[OrigIP]
EVPN type-5 prefix: [5]:[EthTag]:[IPlen]:[IP]

   Network          Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 172.16.0.2:3
*>i[5]:[0]:[24]:[10.0.0.0]
                    172.16.0.5                    100      0 ?

Components

bgpd

Versions

Thanks!

Tuetuopay commented 5 years ago

Closing, this came from my misunderstanding of the gw field. When properly setting the route's nexthop using gobgp's nexthop option, this works perfectly.