3

I am having trouble routing between VRFs using BGP. In my lab there is a hub router with one spoke. I am using MP-BGP to extend VRFs between the two. I want to attach a firewall to the hub with a sub-interface in each VRF. I would like the firewall to run BGP to the hub and be the exchange point between VRFs.

It seems so simple but I cant get it to work due to BGP loop prevention features. If I use iBGP the router drops routes from the firewall stating loop detected via CLUSTER_LIST (despite assigning unique router-ids and cluster-ids per VRF). If I use eBGP the router detects a loop via AS_PATH. I have gotten it to work by redistributing to an IGP and back, but that just seems silly.

I reallllly want this to work with BGP between the firewall and the router. Any suggestions? If not, what would be the next best thing?

SPOKE

ip vrf red
 rd 1:1
 route-target export 1:1
 route-target import 1:1
exit

ip vrf blue
 rd 2:2
 route-target export 2:2
 route-target import 2:2
exit

interface GigabitEthernet1
 description WAN
 ip address 1.1.1.1 255.255.255.0
!

interface loopback 1
 ip vrf forwarding red
 ip address 10.1.1.1 255.255.255.0
exit

interface loopback 2
 ip vrf forwarding blue
 ip address 20.1.1.1 255.255.255.0
exit

l3vpn encapsulation ip MPLS-INT
 transport ipv4 source GigabitEthernet1

route-map region permit 10
 set ip next-hop encapsulate l3vpn MPLS-INT

 !
router bgp 65001
 bgp router-id 1.1.1.1
 bgp log-neighbor-changes
 neighbor 1.1.1.2 remote-as 65001
 neighbor 1.1.1.2 update-source GigabitEthernet1
 !
 address-family ipv4
  neighbor 1.1.1.2 activate
 exit-address-family
 !
 address-family vpnv4
  neighbor 1.1.1.2 activate
  neighbor 1.1.1.2 send-community extended
  neighbor 1.1.1.2 route-map region in
 exit-address-family
 !
 address-family ipv4 vrf red
   redistribute connected
 exit-address-family
 !
 address-family ipv4 vrf blue
  redistribute connected
 exit-address-family

HUB

ip vrf red
 rd 1:1
 route-target export 1:1
 route-target import 1:1
exit

ip vrf blue
 rd 2:2
 route-target export 2:2
 route-target import 2:2
exit

interface GigabitEthernet1
 description WAN
 ip address 1.1.1.2 255.255.255.0
!

interface GigabitEthernet2.1
 description FW VRF RED
 encapsulation dot1Q 1
 ip vrf forwarding red
 ip address 10.2.2.1 255.255.255.252
!

interface GigabitEthernet2.2
 description FW VRF BLUE
 encapsulation dot1Q 2
 ip vrf forwarding blue
 ip address 20.2.2.1 255.255.255.252
!

!
l3vpn encapsulation ip MPLS-INT
 transport ipv4 source GigabitEthernet1

route-map region permit 10
 set ip next-hop encapsulate l3vpn MPLS-INT

 !
router bgp 65001
 bgp router-id 1.1.1.2
 bgp log-neighbor-changes
 neighbor rr peer-group
 neighbor rr remote-as 65001
 neighbor rr update-source GigabitEthernet1
 neighbor 1.1.1.1 peer-group rr
 !
 address-family ipv4
  neighbor rr route-reflector-client
  neighbor 1.1.1.1 activate
 exit-address-family
 !
 address-family vpnv4
  neighbor 1.1.1.1 activate
  neighbor rr send-community extended
  neighbor rr route-reflector-client
  neighbor rr route-map region in
 exit-address-family
 !
 address-family ipv4 vrf red
   redistribute connected
   neighbor 10.2.2.2 remote-as 65001
   neighbor 10.2.2.2 update-source GigabitEthernet2.1
   neighbor 10.2.2.2 route-reflector-client
   neighbor 10.2.2.2 cluster-id 10.2.2.1
   bgp router-id 10.2.2.1
 exit-address-family

 address-family ipv4 vrf blue
   redistribute connected
   neighbor 20.2.2.2 remote-as 65001
   neighbor 20.2.2.2 update-source GigabitEthernet2.2
   neighbor 20.2.2.2 route-reflector-client
   neighbor 20.2.2.2 cluster-id 20.2.2.1
   bgp router-id 20.2.2.1
 exit-address-family

"FIREWALL" (really just another router)



interface GigabitEthernet2.1
 description FW VRF RED
 encapsulation dot1Q 1
 ip address 10.2.2.2 255.255.255.252
!

interface GigabitEthernet2.2
 description FW VRF BLUE
 encapsulation dot1Q 2
 ip address 20.2.2.2 255.255.255.252
!

router bgp 65001
 neighbor 10.2.2.1 remote-as 65001
 neighbor 10.2.2.1 route-reflector-client
 neighbor 20.2.2.1 remote-as 65001
 neighbor 20.2.2.1 route-reflector-client 
exit
6
  • Why does your Hub BGP config have its own IP address (1.1.1.2) in the neighbour statements?
    – user27899
    Aug 6, 2016 at 15:09
  • Also, you have no IGP to provide routing to the BGP next-hops. Firewall has no way of doing a recursive lookup to the BGP next-hops of 1.1.1.1
    – user27899
    Aug 6, 2016 at 15:38
  • There is no need for the route-reflector-client statement on the Firewall as it it shouldn't be reflecting anything
    – user27899
    Aug 6, 2016 at 15:38
  • Hey sorry, I had to type the configs from scratch b/c I dont have access to my lab right now, hopefully that is the extent of the errors. The recursion is fixed via route-maps in the lab setting the correct next hops. The neighbor statement is indeed incorrect (now corrected). The issue I am trying to solve is the BGP loop detection via CLUSTER_LIST or AS_PATH. Aug 6, 2016 at 15:47
  • Have you tried using the "neighbor x.x.x.x allowas in" with eBGP?
    – Ron Trunk
    Aug 6, 2016 at 16:56

1 Answer 1

3

Use the command

neighbor x.x.x.x allowas in

This tells the router not to discard prefixes with its own ASN in the path.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.