cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
9001
Views
5
Helpful
4
Replies

Nexus 7000 - BGP Configuration

Daniel Anderson
Level 1
Level 1

Hi - I've recently run in to a strange scenario having migrated some BGP peerings from a Cisco 6509 Switch on to a Nexus 7000. Scenario is as follows:

Nexus 7000 <L3> Cisco ASR (ASR is running 2 VRFs - VRF A and VRF B) - There are 2 BGP peerings on the 7K - Terminating on the ASR within different VRFs. Which are across 2 different Layer 3 connections.

The connectivity is as above, the ASR has multiple VRFs on which it is learning routes - Currently VRF A is learning a number of routes, for example - 192.168.1.0/24, 192.168.2.0/24 and 192.168.3.0/24 - These routes are being sent to the Nexus device and are visible within the BGP and routing tables as expected. Also, on the Nexus device, we have an aggregate address configured - 192.168.0.0/16 (Summary-Only is NOT configured on this aggregate statement). On the 2nd BGP peering on the Nexus 7000 towards VRF B, I'd expect to see the aggregate address, along with the more specific /24s networks being advertised outwards, however, all I see is the /16 aggregate address. When I run the command 'show ip bgp neigh *.*.*.*' I'm not seeing the more specific routes even being advertised.

Are there some configuration subtleties in place on the NX-OS when it comes to BGP that I may be unaware of - As I've mentioned previously, when this scenario was based on a 6509 running IOS12.2(33) having the multiple BGP peerings as per the above configuration, everything worked as expected. I've played around today with turning off dynamic capability on the 7000, but this has reaped no rewards as yet. I've also labbed this up within GNS3 (based on IOS) and it is also working as I'd expect.

Thoughts appreciated.

Thanks,

Dan

1 Accepted Solution

Accepted Solutions

Sorry, i didn't understand your multi-topology VRF with the first post. From what I understand, you have the peerings on different VRFs but with the same AS.

By default, NX-OS does a peer check and suppress advertisement of eBGP routes to the same AS (like the allow-as in on the receiving side) command but on advertisements, not on received updates. As eBGP neighbors on the same AS should have iBGP between them, this check is performed to avoid unnecessary advertisements.

You have to use the command "disable-peer-as-check" under the neighbor address-family in order to disable this check for your topology. (I have tested this on VIRL lab)

 BGP disable-peer-as-check: Allows external BGP (eBGP) learned routes to advertise to the peers in the same autonomous system.
More info:

http://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus3000/sw/unicast/503_U5_1/l3_nx-os/l3_advbgp.html#wp1197148

You will see this when doing a show bgp ipv4 uni neigh x.x.x.x on the nx-os

 

 For address family: IPv4 Unicast
  BGP table version 16, neighbor version 16
  0 accepted paths consume 0 bytes of memory
  4 sent paths
  ASN override is disabled
  Peer ASN check is disabled

 

Note: You also have to enable the ASN override on the NX side, or the allowas-in on the XR side. By default, XR won't allow routes with the local AS on the AS_PATH. "allowas-in" on XR side would disable this check and as-override on NX side would replace the AS. Either way would work

On XR you also need a route-policy for the eBGP neighbors

 

My basic lab:
NX-SIDE

router bgp 100
  router-id 10.10.10.10
  address-family ipv4 unicast
    network 10.10.10.10/32
    aggregate-address 192.168.0.0/16
  neighbor 10.1.2.2 remote-as 200
    address-family ipv4 unicast
  neighbor 20.1.2.2 remote-as 200
    address-family ipv4 unicast
      disable-peer-as-check

 

XR-SIDE

router bgp 200
 bgp router-id 1.1.1.1
 address-family ipv4 unicast
 !
 address-family vpnv4 unicast
 !
 vrf A
  rd 10:10
  address-family ipv4 unicast
   network 192.168.1.0/24
   network 192.168.2.0/24
   network 192.168.3.0/24
  !
  neighbor 10.1.2.1
   remote-as 100
   address-family ipv4 unicast
    route-policy PASS in
    route-policy PASS out
   !
  !
 !
 vrf B
  rd 20:20
  address-family ipv4 unicast
  !
  neighbor 20.1.2.1
   remote-as 100
   address-family ipv4 unicast
    route-policy PASS in
    allowas-in 3
    route-policy PASS out
   !
  !

///////////

Received routes on XR vrf B:
B    192.168.0.0/16 [20/0] via 20.1.2.1, 00:00:00
B    192.168.1.0/24 [20/0] via 20.1.2.1, 00:04:55
B    192.168.2.0/24 [20/0] via 20.1.2.1, 00:04:55
B    192.168.3.0/24 [20/0] via 20.1.2.1, 00:04:55

View solution in original post

4 Replies 4

eduardopozo56
Level 1
Level 1

Can you issue the "show ip bgp neighbor x.x.x.x advertised-routes" in N7KA? (Using the next iBGP neigh To check if they are being advertised but he is not liking the routes.
----------------
Also, remember that iBGP received networks are only advertised to eBGP and route-reflectors clients. You need full mesh or RR/Confederations, etc for them to be advertised to other iBGP neigh.
"Due to the Border Gateway Protocol (BGP) not propagating any internal BGP (iBGP) learned routes to another iBGP peer, a full iBGP mesh should be maintained within the Autonomous System (AS)"

----------------

Is the next neighbor aware of the ASR's bgp address? remember that next-hop is not changed in iBGP, N7KA might be advertising the network but if the next router doesnt know the next-hop, it wont install the routes on the table.

Thanks for your reply.

I've run the "show ip bgp neighbor x.x.x.x advertised-routes" on the 7KA device that is receiving the routes from the ASR. Where I have a route that is being learnt via the ASR on VRF A, I can then see that the 7K is not advertising it back to the ASR device via the VRF B ebgp connection. The 7K is only running a default routing table, so in effect is allowing us to move control traffic between VRFs that are configured on the ASR devices, that's the theory anyway.

For the peer from 7KA to 7KB I can see that the relevant routes are being advertised as expected. Again, this is an ebgp peering.

We're running ebgp for all our peers, so won't be hitting an iBGP issues.

 

Sorry, i didn't understand your multi-topology VRF with the first post. From what I understand, you have the peerings on different VRFs but with the same AS.

By default, NX-OS does a peer check and suppress advertisement of eBGP routes to the same AS (like the allow-as in on the receiving side) command but on advertisements, not on received updates. As eBGP neighbors on the same AS should have iBGP between them, this check is performed to avoid unnecessary advertisements.

You have to use the command "disable-peer-as-check" under the neighbor address-family in order to disable this check for your topology. (I have tested this on VIRL lab)

 BGP disable-peer-as-check: Allows external BGP (eBGP) learned routes to advertise to the peers in the same autonomous system.
More info:

http://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus3000/sw/unicast/503_U5_1/l3_nx-os/l3_advbgp.html#wp1197148

You will see this when doing a show bgp ipv4 uni neigh x.x.x.x on the nx-os

 

 For address family: IPv4 Unicast
  BGP table version 16, neighbor version 16
  0 accepted paths consume 0 bytes of memory
  4 sent paths
  ASN override is disabled
  Peer ASN check is disabled

 

Note: You also have to enable the ASN override on the NX side, or the allowas-in on the XR side. By default, XR won't allow routes with the local AS on the AS_PATH. "allowas-in" on XR side would disable this check and as-override on NX side would replace the AS. Either way would work

On XR you also need a route-policy for the eBGP neighbors

 

My basic lab:
NX-SIDE

router bgp 100
  router-id 10.10.10.10
  address-family ipv4 unicast
    network 10.10.10.10/32
    aggregate-address 192.168.0.0/16
  neighbor 10.1.2.2 remote-as 200
    address-family ipv4 unicast
  neighbor 20.1.2.2 remote-as 200
    address-family ipv4 unicast
      disable-peer-as-check

 

XR-SIDE

router bgp 200
 bgp router-id 1.1.1.1
 address-family ipv4 unicast
 !
 address-family vpnv4 unicast
 !
 vrf A
  rd 10:10
  address-family ipv4 unicast
   network 192.168.1.0/24
   network 192.168.2.0/24
   network 192.168.3.0/24
  !
  neighbor 10.1.2.1
   remote-as 100
   address-family ipv4 unicast
    route-policy PASS in
    route-policy PASS out
   !
  !
 !
 vrf B
  rd 20:20
  address-family ipv4 unicast
  !
  neighbor 20.1.2.1
   remote-as 100
   address-family ipv4 unicast
    route-policy PASS in
    allowas-in 3
    route-policy PASS out
   !
  !

///////////

Received routes on XR vrf B:
B    192.168.0.0/16 [20/0] via 20.1.2.1, 00:00:00
B    192.168.1.0/24 [20/0] via 20.1.2.1, 00:04:55
B    192.168.2.0/24 [20/0] via 20.1.2.1, 00:04:55
B    192.168.3.0/24 [20/0] via 20.1.2.1, 00:04:55

Fantastic - Exactly what I was looking for. I've tested this morning and it worked exactly as I'd hoped. We have Allowas-In in place already, so once I'd 'disabled peer-as-check' I could see the prefixes being sent as I'd hoped.

Thanks again!!

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: