Networking-Blog

My WordPress Blog

BGP Configuring Peer Groups

You will often want to apply the same policies to most or all of the peers of a particular BGP speaker.
Update policies are usually defined by route maps, filter lists, and distribution lists.

You can reduce the configuration effort by defining a peer group made up of these peers.

A peer group is defined relative to a particular BGP speaker. Two peer groups, eastcoast and leftcoast.
Each of these peer groups is defined for router Chicago, the hub router. Routers Boston, NY, and Miami
have no knowledge of being members of Router Chicago’s eastcoast peer group.

Similarly, routers SanFran, LA, and SanDiego have no knowledge of being members of router
Chicago’s leftcoast peer group.

The following commands configure the eastcoast peer group on router Chicago:

host1(config)#route-map wtset permit 10
host1(config-route-map)#set weight 25
!
host1(config)#router bgp 23
!
host1(config-router)#neighbor eastcoast route-map wtset in
!
!
!
host1(config-router)#neighbor eastcoast peer-group
!
host1(config-router)#neighbor 10.6.6.2 remote-as 12
host1(config-router)#neighbor 10.6.6.2 peer-group eastcoast
!
host1(config-router)#neighbor 10.7.3.2 remote-as 12
host1(config-router)#neighbor 10.7.3.2 peer-group eastcoast
!
host1(config-router)#neighbor 10.4.4.2 remote-as 12
host1(config-router)#neighbor 10.4.4.2 peer-group eastcoast

!
!

The following commands configure the leftcoast peer group on router Chicago:

host1(config-router)#neighbor leftcoast peer-group
!
host1(config-router)#neighbor 10.3.3.2 remote-as 78
host1(config-router)#neighbor 10.3.3.2 peer-group leftcoast
!
host1(config-router)#neighbor 10.3.2.2 remote-as 2143
host1(config-router)#neighbor 10.3.2.2 peer-group leftcoast
!
host1(config-router)#neighbor 10.3.1.2 remote-as 136
host1(config-router)#neighbor 10.3.1.2 peer-group leftcoast

 

 

neighbor peer-group

Two versions of this command exist. Use to create a BGP peer group or to configure
a BGP neighbor to be a member of a peer group.
!
To create a BGP peer group, specify a peerGroupName for the new peer group.
!
To assign members to a peer group, specify an ip-address and a peerGroupName
of a BGP neighbor that belongs to this group.
!
Most of all :
This command takes effect immediately.

BGP Support for Fast Peering Session Deactivation


The BGP Support for Fast Peering Session Deactivation feature introduces an event driven notification

system that allows a Border Gateway Protocol (BGP) process to monitor BGP peering sessions on a
per-neighbor basis.

This feature improves the response time of BGP to adjacency changes by allowing :

BGP to detect an adjacency change and deactivate the terminated session in between standard
BGP scanning intervals. Enabling this feature improves overall BGP convergence.

Restrictions for BGP Support for Fast Peering Session Deactivation :

• This feature is not supported under the IPv6 address family.
• A host route must be available for each peering session that is configured to use BGP fast session
deactivation. If a route is aggregated or is an unreachable non-host route (through a loopback interface)
but still available to the peer, this feature will not be able to track the route and will be unable to close the session.

Information About BGP Support for Fast Peering Session Deactivation

•BGP Hold Timer
•BGP Fast Peering Session Deactivation

BGP Hold Timer

By default, the BGP hold timer is set to run every 180 seconds in Cisco IOS software.
This timer value is set as default to protect the BGP routing process from instability that can be
introduced by peering sessions with other routing protocols. BGP routers typically carry large routing tables,
so frequent session resets are not desirable.

BGP Fast Peering Session Deactivation

BGP fast peering session deactivation improves BGP convergence and response time to adjacency
changes with BGP neighbors. This feature is event driven and configured on a per-neighbor basis.
When this feature is enabled, BGP will monitor the peering session with the specified neighbor.
Adjacency changes are detected and terminated peering sessions are deactivated in between the default
or configured BGP scanning interval.

How to Configure Fast Peering Session Deactivation

This section contains the following task:

•Configuring Fast Session Deactivation for a BGP Neighbor

The neighbor fall-over command was introduced to support BGP fast session deactivation.

SHUT DOWN BGP SESSION BASED ON TRACKED OBJECT

I used a creative approach to create a static route that fits the requirements of the
Fast Peering Deactivation:
a host route toward the BGP next hop pointing at BGP next hop.

Let’s walk through a lab-tested example:

The router is running BGP in AS#65100 and has an EBGP session with 10.0.7.10 in AS#65000:

router bgp 65100
bgp log-neighbor-changes
network 10.0.1.1 mask 255.255.255.255
neighbor 10.0.7.10 remote-as 65000

First we have to create the track object that will cause the BGP session termination. It can track
anything – you can track interface state, use IP SLA and ping the firewall, or even use EEM to
trigger time-based  (or other event-based) session shutdown. I decided to track the state of the LAN interface.
!
track 10 interface FastEthernet0/0 ip routing
carrier-delay

Next, create a host route for the BGP next hop pointing to the next hop itself.
If you use a PPP interface to connect to the BGP next hop, make sure you disable
peer neighbor-route, otherwise the router creates a competing host route for the BGP next hop.

ip route 10.0.7.10 255.255.255.255 Serial1/0 10.0.7.10 track 10
!
interface Serial1/0
description Link to AS65000
ip address 10.0.7.9 255.255.255.252
encapsulation ppp
no peer neighbor-route

We need a prefix-list and a route-map to match the host route toward the BGP next hop:

ip prefix-list BGP_OK seq 5 permit 10.0.7.10/32
!
route-map BGP_OK permit 10
match ip address prefix-list BGP_OK
!
And finally, we can configure the fast BGP session deactivation on the EBGP session:

router bgp 65100
neighbor 10.0.7.10 fall-over route-map BGP_OK

Test#1 – shut down the LAN interface. BGP session is shut down almost immediately
(you can fine-tune the delay with track object parameters).

A1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
A1(config)#int fa 0/0
A1(config-if)#shut
A1(config-if)#
15:27:55.719: %LINK-5-CHANGED: Interface FastEthernet0/0, changed state to
administratively down
15:27:56.383: %TRACKING-5-STATE: 10 interface Fa0/0 ip routing Up->Down
15:27:56.415: %BGP-5-ADJCHANGE: neighbor 10.0.7.10 Down Route to peer lost
15:27:56.415: %BGP_SESSION-5-ADJCHANGE: neighbor 10.0.7.10 IPv4 Unicast
topology base removed from session Route to peer lost
15:27:56.719: %LINEPROTO-5-UPDOWN: Line protocol on Interface
FastEthernet0/0, changed state to down

Test#2 – re-enable the LAN interface. BGP session is reestablished in less than a second. Perfect 😉

A1(config-if)#no shut
A1(config-if)#
15:29:22.211: %LINK-3-UPDOWN: Interface FastEthernet0/0, changed state to up
15:29:22.395: %TRACKING-5-STATE: 10 interface Fa0/0 ip routing Down->Up
15:29:22.511: %BGP-5-ADJCHANGE: neighbor 10.0.7.10 Up
15:29:23.211: %LINEPROTO-5-UPDOWN: Line protocol on Interface
FastEthernet0/0, changed state to up

 

In Summary :

router bgp 65100
bgp log-neighbor-changes
network 10.0.1.1 mask 255.255.255.255
neighbor 10.0.7.10 remote-as 65000
!
 track 10 interface FastEthernet0/0 ip routing
carrier-delay
!
ip route 10.0.7.10 255.255.255.255 Serial1/0 10.0.7.10 track 10
!
interface Serial1/0
no peer neighbor-route
! 
 ip prefix-list BGP_OK seq 5 permit 10.0.7.10/32
!
route-map BGP_OK permit 10
match ip address prefix-list BGP_OK
!
router bgp 65100
neighbor 10.0.7.10 fall-over route-map BGP_OK

BGP WEIGHT/PREFERENCE

Weight Attribute

 

The weight attribute is a Cisco-defined attribute. This attribute uses weight to select a best path. The weight is assigned
locally to the router. The value only makes sense to the specific router. The value is not propagated or carried through any
of the route updates. A weight can be a number from 0 to 65,535.

Paths that the router originates have a weight of 32,768 by default, and other paths have a weight of 0.

Routes with a higher weight value have preference when multiple routes to the same destination exist.

Look at the example in this section.

RTA has learned about network 175.10.0.0 from AS4.
RTA propagates the update to RTC.
RTB has also learned about network 175.10.0.0 from AS4.
RTB propagates the update to RTC.
RTC now has two ways to reach 175.10.0.0 and has to decide which way to go.

If you set the weight of the updates on RTC that come from RTA so that the weight is greater than the weight of updates
that come from RTB, you force RTC to use RTA as a next hop to reach 175.10.0.0.

Multiple methods achieve this weight set:

  • Use the neighbor command.
    • neighbor{ip-address | peer-group}weight weight
  • Use AS_PATH access lists.
    • ipas-pathaccess-list access-list-number {permit|deny} as-regular-expression neighbor ip-address filter-list access-list-number weightweight
      !
      !— The route to 175.10.0.0 from RTA has a 200 weight.
       
  • Use route maps.
  • RTC#
  • router bgp 300
  • neighbor 1.1.1.1 remote-as 100
  • neighbor 1.1.1.1 weight 200
  • !
  • !— The route to 175.10.0.0 from RTB has a 100 weight.
  • neighbor 2.2.2.2 remote-as 200
  • neighbor 2.2.2.2 weight 100

RTA, which has a higher weight value, has preference as the next hop.

!
!

You can achieve the same outcome with IP AS_PATH and filter lists.

RTC#

router bgp 300

neighbor 1.1.1.1 remote-as 100

neighbor 1.1.1.1 filter-list 5 weight 200

neighbor 2.2.2.2 remote-as 200

neighbor 2.2.2.2 filter-list 6 weight 100

!— This only permits path 100.

ip as-path access-list 5 permit ^100$

ip as-path access-list 6 permit ^200$

!
! 

You also can achieve the same outcome with the use of route maps.

RTC#

router bgp 300

neighbor 1.1.1.1 remote-as 100

neighbor 1.1.1.1 route-map setweightin in

neighbor 2.2.2.2 remote-as 200

neighbor 2.2.2.2 route-map setweightin in

…

ip as-path access-list 5 permit ^100$

 !

route-map setweightin permit 10

match as-path 5

set weight 200

!— Anything that applies to access list 5, such as packets from AS100, has weight 200.

 

route-map setweightin permit 20

set weight 100

!— Anything else has weight 100.

 

Local Preference Attribute

 

Local preference is an indication to the AS about which path has preference to exit the AS in order to reach a certain network.
A path with a higher local preference is preferred more. The default value for local preference is 100.

 

Unlike the weight attribute, which is only relevant to the local router, local preference is an attribute that routers exchange in the same AS.

You set local preference with the issue of the bgp default local-preference value command.
You can also set local preference with route-maps, as the example in this section demonstrates:

 

The bgp default local-preference command sets the local preference on the updates out of the router that go to peers
in the same AS. In the diagram in this section, 

AS256 receives updates about 170.10.0.0 from two different sides of the organization. Local preference helps you determine
which way to exit AS256 in order to reach that network. 

Assume that RTD is the exit point preference. This configuration sets the local preference for updates that come from 
AS300 
to 200 and for updates that come from AS100 to 150:

RTC#

router bgp 256

neighbor 1.1.1.1 remote-as 100

neighbor 128.213.11.2 remote-as 256

bgp default local-preference 150

RTD#

router bgp 256

neighbor 3.3.3.4 remote-as 300

neighbor 128.213.11.1 remote-as 256

bgp default local-preference 200

In this configuration,

RTC sets the local preference of all updates to 150.
The same RTD sets the local preference of all updates to 200.

There is an exchange of local preference within AS256.

Therefore, both RTC and RTD realize that network 170.10.0.0 has a higher local preference when updates come from AS300 rather than from AS100. All traffic in AS256 that has that network as a destination transmits with RTD as an exit point.

The use of route maps provides more flexibility.

In the example in this section,

All updates that RTD receives are tagged with local preference 200 when the updates reach RTD. Updates that come from AS34 also are tagged with the local preference of 200. This tag can be unnecessary. For this reason, you can use route maps to specify the specific updates that need to be tagged with a specific local preference.

Here is an example:

RTD#

router bgp 256

neighbor 3.3.3.4 remote-as 300

neighbor 3.3.3.4 route-map setlocalin in

neighbor 128.213.11.1 remote-as 256

….

ip as-path access-list 7 permit ^300$

…

 

route-map setlocalin permit 10

match as-path 7

set local-preference 200

 

route-map setlocalin permit 20

set local-preference 150

With this configuration, any update that comes from AS300 has a local preference of 200. Any other updates, such as updates that come from AS34, have a value of 150.

 

CISCO BGP TAG

I am able to fail a remote MPLS location (running iBGP) and have its IP Traffic traverse an IPSEC Tunnel
across the Internet and into an ASA. At the core router, I point that backup traffic to that ASA.
While the failover time is not instantaneous, it does resume in less than 30 seconds.

Network Details;

Remote Site1: 10.1.60.1/24 and Remote Site2: 10.1.70.1/24
Core Router: 10.1.2.1/24 with Failover ASA: 10.1.2.5/25

Here is what the Core Route configuration looks like;
!
router bgp 111
network 10.1.60.0 mask 255.255.255.0 route-map NoStatic backdoor
network 10.1.70.0 mask 255.255.255.0 route-map NoStatic2 backdoor
!
ip route 10.1.60.0 255.255.255.0 10.1.2.5 220 tag 220
ip route 10.1.70.0 255.255.255.0 10.1.2.5 225 tag 225
!
route-map NoStatic permit 10
match tag 220
set metric 220
!
route-map NoStatic2 permit 20
match tag 225
set metric 225

BGP Address-family Ipv4 Is Used

 To advertise routes we need to use MP-iBGP and hence to enable this MP-iBGP we need to use
address-family VPNv4. Then by default the neighbors in this family are deactivated by default and hence
we need to use activate command.

once we enable the vpn family the neighbors on the global bgp will deactivated in order to stop that we
need to put the neighbors in address-family ip4 and then activate it. It is mainly used in MPLS VPN environmen
t.

“address-family” command is necessary when the packets go through MPLS backbone.

You need to put two commands to enable MP-BGP session 1) activate 2) send community.

BGP DEFAULT ROUTE

There is two upstream links and runs BGP on both. Since this router is low on RAM, it cannot accept
full routing, so it is just announcing it’s IP prefix and using static default routing toward upstream ISPs.

router bgp 65100
neighbor 10.0.1.2 remote-as 65001
neighbor 10.0.1.6 remote-as 65002
!
ip route 0.0.0.0 0.0.0.0 10.0.1.2
ip route 0.0.0.0 0.0.0.0 10.0.1.6 250

I’m sure the long-time readers of my blog immediately figured out where the catch is: if the upstream router
dies, but the interface stays up, the outbound traffic is blackholed.  Reliable static routing might be
a solution, but his router is running an old IOS version. Obviously it’s time for yet another rarely known
BGP feature: the BGP default route.

To announce a default route to a BGP neighbor, you can configure neighbor default-originate.
Once you’ve configured default route advertising with the neighbor default-originate, it’s announced to
the neighbor even if the router doesn’t have the default route itself.

The default route advertised to a BGP neighbor with the neighbor default-originate does not pass through
BGP output filters, so you cannot filter it.

To solve this problem, you’d have to reconfigure BGP on E1 and E2 as follows
(the ip as-path access list just ensures nothing else is sent to the customer router; obviously you could use a route-map instead) :

router bgp 65002
neighbor 10.0.1.5 remote-as 65100
neighbor 10.0.1.5 default-originate
neighbor 10.0.1.5 filter-list 1 out
!
ip as-path access-list 1 deny .*

Now that the default route is advertised via BGP, there is no need for a static default, and the default route
will be removed (and replaced with the backup one) if the BGP neighbor disappears.

Router Configuration :

GW
hostname GW
!
interface FastEthernet0/0
ip address 10.0.1.1 255.255.255.252
!
interface FastEthernet1/0
ip address 10.0.1.5 255.255.255.252
!
router bgp 65100
no synchronization
bgp log-neighbor-changes
neighbor 10.0.1.2 remote-as 65001
neighbor 10.0.1.6 remote-as 65002
neighbor 10.0.1.6 route-map WEIGHT in
no auto-summary
!
!
route-map WEIGHT permit 10
set weight 10

!
!

E1

hostname E1
!
interface FastEthernet0/0
ip address 10.0.1.2 255.255.255.252
!
!
router bgp 65001
no synchronization
bgp log-neighbor-changes
neighbor 10.0.1.1 remote-as 65100
neighbor 10.0.1.1 default-originate
neighbor 10.0.1.1 route-map PREFERENCE in
neighbor 10.0.1.1 filter-list 1 out
no auto-summary
!
!
ip as-path access-list 1 deny .*
!
route-map PREFERENCE permit 10
set local-preference 200

!
!

E2

hostname E2
!
interface FastEthernet0/0
ip address 10.0.1.6 255.255.255.252
!
router bgp 65002
no synchronization
bgp log-neighbor-changes
neighbor 10.0.1.5 remote-as 65100
neighbor 10.0.1.5 default-originate

 

Summary :

E1 router link will take preference since it has a preference value set within it’s
route-map of 200 – default is 100.

But on GW router we have set weight towards neighbor E2 of 5, default is 0, the
higher the weight will cause 
this link to take precedence. Weight will be outgoing
towards the router.

You either use weight or preference value, but not both.

Setting a preference value of 200 on E1 will cause incoming routes from GW router to be tagged with this value making E1 router the primary link.

Keep in mind if we have both Weight and Preference value set, then Weight will take
more preference since
it is outgoing towards it’s neighbor router. 

 

IBGP LAB ROUTING – REDUNDANT LINK

Here is a Lab scenerio providing 3 router within an IBGP. Creating a primary and secondary redundant
link using local precedence value with route-map statement.

R0 router is to be the primary link and R2 is the redundant link.
R1 is to tag routes going to neighbor R0 with a preference value of 200, thus making it a primary link
since the defaulf preference value is 100 and the highest pref set than 100 will become the main link
.

RO

interface Loopback0
ip address 100.0.0.1 255.255.255.255
!

interface FastEthernet0/0
ip address 192.168.0.1 255.255.255.252
!
interface FastEthernet0/1
ip address 192.168.0.5 255.255.255.252
!
router bgp 100
no synchronization
bgp log-neighbor-changes
neighbor 1.1.1.1 remote-as 100
neighbor 1.1.1.1 ebgp-multihop 2
neighbor 1.1.1.1 update-source Loopback0
neighbor 2.2.2.2 remote-as 100
neighbor 2.2.2.2 ebgp-multihop 2
neighbor 2.2.2.2 update-source Loopback0
neighbor 192.168.0.2 remote-as 100
neighbor 192.168.0.6 remote-as 100
no auto-summary

!
ip route 1.1.1.1 255.255.255.255 192.168.0.2
ip route 2.2.2.2 255.255.255.255 192.168.0.6
!
!

R1

interface Loopback1
ip address 1.1.1.1 255.255.255.255
!
interface FastEthernet0/0
ip address 192.168.0.2 255.255.255.252
!
interface FastEthernet0/1
ip address 192.168.0.9 255.255.255.252
!

router bgp 100
no synchronization
bgp log-neighbor-changes
neighbor 2.2.2.2 remote-as 100
neighbor 2.2.2.2 ebgp-multihop 2
neighbor 2.2.2.2 update-source Loopback1
neighbor 100.0.0.1 remote-as 100
neighbor 100.0.0.1 ebgp-multihop 2
neighbor 100.0.0.1 update-source Loopback1
neighbor 192.168.0.1 remote-as 100
neighbor 192.168.0.1 route-map PREFERENCE in
neighbor 192.168.0.10 remote-as 100
no auto-summary
!
route-map PREFERENCE permit 10
set local-preference 200
!
ip route 2.2.2.2 255.255.255.255 192.168.0.10
ip route 100.0.0.1 255.255.255.255 192.168.0.1

 

R2

interface Loopback2
ip address 2.2.2.2 255.255.255.0
!
interface FastEthernet0/0
ip address 192.168.0.6 255.255.255.252
!
interface FastEthernet0/1
ip address 192.168.0.10 255.255.255.252
!
router bgp 100
no synchronization
bgp log-neighbor-changes
neighbor 1.1.1.1 remote-as 100
neighbor 1.1.1.1 ebgp-multihop 2
neighbor 1.1.1.1 update-source Loopback2
neighbor 100.0.0.1 remote-as 100
neighbor 100.0.0.1 ebgp-multihop 2
neighbor 100.0.0.1 update-source Loopback2
neighbor 192.168.0.5 remote-as 100
neighbor 192.168.0.9 remote-as 100
no auto-summary
!
ip route 1.1.1.1 255.255.255.255 192.168.0.9
ip route 100.0.0.1 255.255.255.255 192.168.0.5

 

CISCO IBGP COMMUNITY NO-EXPORT

This is a working configuration, This will redistribute connected routes based on route-map
configuration LOOPBACK1 and also will only advertise the connected route to neighbor
peer address 2.2.2.2 with configured route-map COMMUNITY.

The community is set to “no-export“, meaning the peer address of 2.2.2.2 will not advertise
this route to other peer’s connected to this peer.

interface Loopback0
ip address 100.0.0.1 255.255.255.255
!
router ospf 1
log-adjacency-changes
network 100.0.0.1 0.0.0.0 area 0
!

router bgp 100
no synchronization
bgp log-neighbor-changes
redistribute connected route-map LOOPBACK1
neighbor 2.2.2.2 remote-as 100
neighbor 2.2.2.2 update-source Loopback0
neighbor 2.2.2.2 send-community
neighbor 2.2.2.2 route-map COMMUNITY out
!
!
ip access-list standard BGP_LOOPBACK1_ADVERTISE
permit 100.0.1.0 0.0.0.255
!
ip access-list standard LOOPBACK1_COMMUNITY
permit 100.0.1.0 0.0.0.255
!
!
route-map LOOPBACK1 permit 10
match ip address BGP_LOOPBACK1_ADVERTISE
!
route-map LOOPBACK1 deny 20
!
!
route-map COMMUNITY permit 10
match ip address LOOPBACK1_COMMUNITY
set community no-export
!
route-map COMMUNITY permit 20

BGP SET COMMUNITY

Adds a community set clause to the route map.

set community community-number [additive | none | no-export | no-advertise | local-as]

community-number
Identifies a community number. Valid values are integer from 1 to 4294967200.

no-export
All routes received carrying this value are not advertised outside a BGP confederation boundary.

no-advertise
All routes received carrying this value are not advertised to other BGP peers.

additive
Adds the community to the already existing communities

none
Removes the community attribute from route prefixes that pass the route-map.

local-as
All routes received carrying this value are not advertised outside the local autonomous system.

Use the route-map command to create a route map. Use the various match and set commands to define
the conditions for redistributing routes between protocols or instances of the same protocol.

A community is a group of destinations which share the community attribute.
A BGP speaker can use the community attribute to control which routing information it accepts or
distributes to neighbors. A BGP speaker can append the community attribute to routes it receives that
do not already have the attribute.

Factory Default: No communities attributes defined.

Command Mode: Route map configuration.

Example 1:

In the following example, the set community command specifies that routes that
pass as-path access list 3 have their community attribute set to 108:

route-map community108 permit 10
match as-path 3
set community 108
!
ip as-path access-list 3 permit 1.1.1.1

Example 2:

In the following example, the set community command specifies that routes that
pass as-path access list 3 have community set to no-export and are not advertised to any EBGP peers.

route-map no-export permit 10
match as-path 3
set community no-export

ip as-path access-list 3 permit 2.2.2.2

Here is what is needed in order to advertise these route-map’s within bgp with
set community to take effect.

router bgp 100
neighbor 1.1.1.1 send-community
neighbor 1.1.1.1 route-map community108 out
!
!
router bgp 100
neighbor 2.2.2.2 send-community
neighbor 2.2.2.2 route-map no-export  out

BGP Community Redistribute Static Routes

For example, if you use static routing with your customers and want to
redistribute the static routes into BGP,

use the following configuration (I’ve used tag 123 to tag static routes that
should get inserted into BG
P).

router bgp 65001
redistribute static route-map StaticToBGP
!
route-map StaticToBGP permit 10
match tag 123
set community no-export additive

When you configure a static route toward the IP subnet 10.1.2.0/24 …

ip route 10.1.2.0 255.255.255.0 Null0 tag 123

… it’s automatically inserted in the BGP table and marked with the no-export community:

Diagnostics
R1#show ip bgp 10.1.2.0

BGP routing table entry for 10.1.2.0/24, version 3
Advertised to update-groups:
1
Local
0.0.0.0 from 0.0.0.0 (10.0.1.1)
Origin incomplete, metric 0, localpref 100, weight 32768, valid, sourced, best
Community: no-export