Category Archives: BGP

Border Gateway Protocol

BGP Weight Path Attribute in Network Failover Scenarios

Note: The default weight for learned routes is 0 and the default weight for a locally originated route is 32768

IGP-BGP0401

Using EIGRP

CE01#sh ip eigrp topology
EIGRP-IPv4 Topology Table for AS(10)/ID(172.1.1.1)
Codes: P – Passive, A – Active, U – Update, Q – Query, R – Reply,
r – reply Status, s – sia Status
P 192.168.1.1/32, 1 successors, FD is 2560002816, tag is 10
via 3.3.3.2 (2560002816/2560000256), FastEthernet2/0
P 3.3.3.0/30, 1 successors, FD is 28160
via Connected, FastEthernet2/0
P 192.168.2.2/32, 1 successors, FD is 2560002816, tag is 10
via 3.3.3.2 (2560002816/2560000256), FastEthernet2/0
P 172.1.1.1/32, 1 successors, FD is 156160
via 3.3.3.2 (156160/128256), FastEthernet2/0

CE01#sh ip bgp
BGP table version is 9, local router ID is 3.3.3.1
Status codes: s suppressed, d damped, h history, * valid, > best, i – internal,
r RIB-failure, S Stale
Origin codes: i – IGP, e – EGP, ? – incomplete

Network Next Hop Metric LocPrf Weight Path
*> 3.3.3.0/30 0.0.0.0 0 32768 ?
*> 172.1.1.1/32 3.3.3.2 156160 32768 ?
* 192.168.1.1/32 1.1.1.1 0 10 i
*> 3.3.3.2 2560002816 32768 ?
* 192.168.2.2/32 1.1.1.1 0 10 i
*> 3.3.3.2 2560002816 32768 ?

CE01#sh ip route
D 172.1.1.1 [90/156160] via 3.3.3.2, 00:05:07, FastEthernet2/0
192.168.1.0/32 is subnetted, 1 subnets
D EX 192.168.1.1 [170/2560002816] via 3.3.3.2, 00:02:23, FastEthernet2/0
192.168.2.0/32 is subnetted, 1 subnets
D EX 192.168.2.2 [170/2560002816] via 3.3.3.2, 00:02:23, FastEthernet2/0

CE01#sh run | sec router
router eigrp 10
network 3.3.3.0 0.0.0.3
router bgp 20
no synchronization
bgp log-neighbor-changes
redistribute eigrp 10
neighbor 1.1.1.1 remote-as 10
no auto-summary

##########################################
CE02#sh run | sec router
router eigrp 10
network 3.3.3.0 0.0.0.3
network 172.1.1.0 0.0.0.255
redistribute bgp 20
router bgp 20
no synchronization
bgp log-neighbor-changes
neighbor 2.2.2.1 remote-as 10

CE02#sh ip bgp
BGP table version is 4, local router ID is 3.3.3.2
Status codes: s suppressed, d damped, h history, * valid, > best, i – internal,
r RIB-failure, S Stale
Origin codes: i – IGP, e – EGP, ? – incomplete
Network Next Hop Metric LocPrf Weight Path
*> 192.168.1.1/32 2.2.2.1 0 10 i
*> 192.168.2.2/32 2.2.2.1 0 10 i
#########################################################################

CE01#sh ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
172.1.1.1 1 FULL/DR 00:00:31 3.3.3.2 FastEthernet2/0

CE01#sh ip ospf database
OSPF Router with ID (3.3.3.1) (Process ID 1)

Router Link States (Area 0)
Link ID ADV Router Age Seq# Checksum Link count
3.3.3.1 3.3.3.1 17 0x80000002 0x00FB0D 1
172.1.1.1 172.1.1.1 18 0x80000003 0x0024D4 2
Net Link States (Area 0)
Link ID ADV Router Age Seq# Checksum
3.3.3.2 172.1.1.1 18 0x80000001 0x003494
Type-5 AS External Link States
Link ID ADV Router Age Seq# Checksum Tag
192.168.1.1 172.1.1.1 94 0x80000001 0x006CA2 10
192.168.2.2 172.1.1.1 94 0x80000001 0x0057B5 10
CE01#sh ip bgp
BGP table version is 29, local router ID is 3.3.3.1
Status codes: s suppressed, d damped, h history, * valid, > best, i – internal,
r RIB-failure, S Stale
Origin codes: i – IGP, e – EGP, ? – incomplete
Network Next Hop Metric LocPrf Weight Path
*> 3.3.3.0/30 0.0.0.0 0 32768 ?
*> 172.1.1.1/32 3.3.3.2 2 32768 ?
* 192.168.1.1/32 1.1.1.1 0 10 i
*> 3.3.3.2 2 32768 ?
* 192.168.2.2/32 1.1.1.1 0 10 i
*> 3.3.3.2 2 32768 ?

CE01#sh ip route
Gateway of last resort is not set
O 172.1.1.1 [110/2] via 3.3.3.2, 00:06:47, FastEthernet2/0
192.168.1.0/32 is subnetted, 1 subnets
O E1 192.168.1.1 [110/2] via 3.3.3.2, 00:05:13, FastEthernet2/0
192.168.2.0/32 is subnetted, 1 subnets
O E1 192.168.2.2 [110/2] via 3.3.3.2, 00:05:13, FastEthernet2/0

CE01# sh run | sec router
router ospf 1
log-adjacency-changes
router bgp 20
no synchronization
bgp log-neighbor-changes
redistribute ospf 1 match internal external 1 external 2
neighbor 1.1.1.1 remote-as 10
no auto-summary

##################################
CE02#sh ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
3.3.3.1 1 FULL/BDR 00:00:33 3.3.3.1 FastEthernet2/0

CE02#sh run | sec router
router ospf 1
log-adjacency-changes
redistribute bgp 20 metric-type 1 subnets
router bgp 20
no synchronization
bgp log-neighbor-changes
neighbor 2.2.2.1 remote-as 10
no auto-summary

Solution:
Set the Weight path attribute to 40000 for all routes received from the BGP peer.

CE01(config)#router bgp 20
CE01(config-router)#neighbor 1.1.1.1 weight 4000

CE01#sh ip bgp
Network Next Hop Metric LocPrf Weight Path
*> 192.168.1.1/32 1.1.1.1 4000 10 i
*> 192.168.2.2/32 1.1.1.1 4000 10 i

CE01#sh ip route
O 172.1.1.1 [110/2] via 3.3.3.2, 00:56:16, FastEthernet2/0
192.168.1.0/32 is subnetted, 1 subnets
B 192.168.1.1 [20/0] via 1.1.1.1, 00:00:20
192.168.2.0/32 is subnetted, 1 subnets
B 192.168.2.2 [20/0] via 1.1.1.1, 00:00:20

Reference:
https://www.rogerperkin.co.uk/routing-protocols/bgp/bgp-weight-attribute/
https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/213285-understand-the-importance-of-bgp-weight.html

BGP OUTBOUND ROUTE FILTERING (BGP ORF)

Outbound Route Filtering Capability for BGP-4 is currently an IETF draft (http://www.ietf.org/internet-drafts/draft-ietf-idr-route-filter-16.txt) that describes an optimization on how prefix filtering can occur between a Customer Edge (CE) router and a Provider Edge (PE) router that are exchanging IPv4 unicast BGP prefixes. In the design we saw above the upstream PE router sent the full BGP table downstream to the CE router, and filtering was applied inbound on the downstream CE. With BGP ORF the downstream CE router dynamically tells the upstream PE router what routes to filter *outbound*. This means that the downstream CE router will only receive update messages about the prefixes that it wants.

Implementation wise the first step of this feature is for the BGP neighbors to negotiate that they both support the BGP ORF capability. Configuration-wise this looks as follows:

AS100_PE#
router bgp 100
neighbor 10.0.0.200 remote-as 200
!
address-family ipv4
neighbor 10.0.0.200 capability orf prefix-list receive
neighbor 204.12.25.254 activate
exit-address-family

AS200_CE#
router bgp 200
neighbor 10.0.0.100 remote-as 100
!
address-family ipv4
neighbor 10.0.0.100 capability orf prefix-list send
neighbor 10.0.0.100 prefix-list AS_100_INBOUND in
exit-address-family
!

Verification:
AS100_PE#show ip bgp neighbors 10.0.0.200 | begin AF-dependant capabilities:
AS200_CE#show ip bgp neighbors 10.0.0.100 | begin AF-dependant capabilities:

Next, AS 200’s CE router tells AS 100’s PE router which prefixes it wants to receive. The logic of this configuration is that AS 200 is “sending” a prefix-list of what routes it wants, while AS 100 is “receiving” the prefix-list of what the downstream neighbor wants. The reception of the prefix-list by the upstream PE can be verified as follows.

INE LINK

BGP Metric (xxx)

# show ip bgp
65000
1.1.1.1 (metric 1001) from 1.1.1.1 (1.1.1.1) <—– cumulative cost
Origin IGP, metric 0, localpref 100, valid, internal
Extended Community: RT:6055:55
rx pathid: 0, tx pathid: 0
Refresh Epoch 2
65000, (received-only)
1.1.1.1 (metric 1001) from 1.1.1.1 (1.1.1.1)
Origin IGP, metric 0, localpref 100, valid, internal
rx pathid: 0, tx pathid: 0
Refresh Epoch 1
65000
2.2.2.2 from 2.2.2.2 (172.16.3.3)
Origin IGP, localpref 100, valid, external, best
Extended Community: RT:6055:55
rx pathid: 0, tx pathid: 0x0
Refresh Epoch 1
65000, (received-only)
2.2.2.2 from 2.2.2.2 (172.16.3.3)
Origin IGP, localpref 100, valid, external
rx pathid: 0, tx pathid: 0

Metric () – Shows the metric learned to reach the next-hop that has access to the specific subnet.
Metric – The blue metric reflects the BGP metric for the specific subnet you try to reach. It's the same for both entries in your example.
https://community.cisco.com/t5/switching/bgp-metric-x-vs-igp-metric-how-to-change-the-bgp-quot-ttl-quot/td-p/3226262

router ospf 100 vrf xnet-main
router-id 9.9.9.9
auto-cost reference-bandwidth 1000000
passive-interface default
no passive-interface G1
default-information originate always metric 10

Routing entry for 1.1.1.1/32
Known via "ospf 100", distance 110, metric 1001, type intra area
Last update from 192.168.1.2 on GigabitEthernet0/1, 7w0d ago
Routing Descriptor Blocks:
* 192.168.1.2, from 1.1.1.1, 7w0d ago, via GigabitEthernet0/1
Route metric is 1001, traffic share count is 1

xxxx#sh ip ospf

Reference bandwidth unit is 1010000 mbps

Formula:
OSPF cost = Ref.BW /Interface. BW
1000000 1000(mbps)
= 1000

BGP Aggregate Address

### R1 BGP CONFIGURATION ###
router bgp 10
no synchronization
bgp log-neighbor-changes
network 37.1.1.0 mask 255.255.255.0
neighbor 1.1.1.2 remote-as 20
neighbor 1.1.1.2 soft-reconfiguration inbound

R1#sh ip bgp neighbors 1.1.1.2 advertised-routes
BGP table version is 5, local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i – internal,
r RIB-failure, S Stale
Origin codes: i – IGP, e – EGP, ? – incomplete

Originating default network 0.0.0.0

Network Next Hop Metric LocPrf Weight Path
*> 37.1.1.0/26 37.1.1.252 0 32768 ?
*> 37.1.1.64/26 0.0.0.0 0 32768 ?
*> 37.1.1.128/25 0.0.0.0 0 32768 ?
Without route summmarizaton we are adversting multiple 37.1.1.0 prefixes towards to the neighbor.

Suppressing more-specific routes

The keyword summary-only filters all more-specific routes which belong to the aggregate-address and only the summary will be advertised.

R1#sh run | sec router bgp
router bgp 10
no synchronization
bgp log-neighbor-changes
network 37.1.1.0 mask 255.255.255.0
aggregate-address 37.1.1.0 255.255.255.0 summary-only

R1#sh ip bgp neighbors 1.1.1.2 advertised-routes
Originating default network 0.0.0.0

Network Next Hop Metric LocPrf Weight Path
*> 37.1.1.0/24 0.0.0.0 32768 i

What is Route Leaking
1. When running a multi MPLS network, it can be useful to leak routes between VRFs. A classic use for this would be to leak your link to a management VRF, or assigning a management address to your CE routers as a /32 address and leaking that. Other uses could be leaking public ip addresses to a separate VRF, to be handled by a different router than the LAN addresses. It is necessary to filter your route leaking to make sure that only non-overlapping addresses are leaked, and it is important to make sure that one VRF doesn’t have access to routes of another VRF.

2. 2 ways to leak one vrf to another: –
1. // statically leak a vrf to global routing table and vice versa
2.// using Rd and rt values leak it to mp bgp (other vrfs) and then redistribute to other dynamic routing protocols in that vrf.

3. In ISP environment they use common MPLS core for multiple customer,,if Ur having multiple sites like London-A and Delhi -A and another end London-B and Delhi-B,if u want to make communications between them we can do that, for that isp MPLS core routers use RD and RT concept ,edge router add RT and same applied to both site if they match they successfully communicate without any issue,,and routes of A gives to another end site A only ,,but if RT mismatch then routes will get leak and site A which is london-A route will get into another end site which is Delhi -2.

BGP – ROUTE REFLECTOR
1. Service provider environment – RR are installed to share routes with multiple PEs rather than building igbp with all PEs

2. Generally service provider must have RR. Those RR can be redundant to each other or shared traffic based on Geo location.

3. 1. RR is used to break the ibgp rule.
2. While using RR there are 2 more attributes introduced in bgp which are originator id and cluster id.
3. These two attributes also provide a loop prevention mechanism in ibgp while using RR.

http://packetpushers.net/bgp-rr-design-part-1/

AS loop detection, As-override and Allowas-in

BGP loop prevention with AS_PATH

“As RFC 4271 says, “AS loop detection is done by scanning the full AS path (as specified in the AS_PATH attribute), and checking that the autonomous system number of the local system does not appear in the AS path”.”

“BGP was implemented the way it was ie. it is the responsibilty of the local AS to control what enters and leaves that AS in terms of route advertisements.”

https://supportforums.cisco.com/t5/wan-routing-and-switching/bgp-loop-prevention-with-as-path/td-p/1398131

ASoverde5242018
What is neighbor as-override and neighbor allowas-in command?

The provider should configure its PE routers to “masquerade” the ASN 65001 in these updates using the neighbor as-override command. This will cause all occurrences of the ASN 65001 to be rewritten to the provider’s own ASN of 1234, so the AS_PATH as seen by CE routers would in fact be “1234 1234”.

Ex. Provider AS is 3939, When PE enable as-override to it’s neighbor which in my case is R17(112.1.1.2) the output will be like this.

Configuration:
XYZ-PE-R16(config)#router bgp 3939
XYZ-PE-R16(config-router)#address-family ipv4 vrf custq
XYZ-PE-R16(config-router-af)#neighbor 112.1.1.2 as-override

XYZ-PE-R16#sh ip bgp vpnv4 vrf custq neighbors 112.1.1.2 adver

peoveradout52418
Branch CE advertise routes with AS 555 to PE then advertise again out to R17-CE.

Verification on R17-CE using show ip bgp:
peovera02dout52418 AS 555 has been replace/override to 3939 which belongs to AS555.

Note: This command is only available for MPLS L3VPN deployments and cannot be used in all situations.

“Therefore, the CE router, itself being in ASN 65001, can be instructed to bypass the anti-routing-loop check in BGP and accept even those routes that already carry the AS 65001 in their AS_PATH attribute. This is exactly the meaning of the neighbor allowas-in command.”

Ex. CE1-R17 advertised 192.168.8.55/32 routes to CE-R5 (Branch), We can enable allowas-in @ CE side.

Configuration(CE02):
OLD-Customer-B(config-router)#router bgp 555
OLD-Customer-B(config-router)#neighbor 172.16.2.1(PE) allowas-in 1

The allowas-in command permits multiple occurences of the same ASN (In this case the ASN of the SP) in the as-path the ASN of BGP speaker without denying the route. The number you can configure if from 1 to 10, specifying the number of times athat the ASN is allowed in the AS-Path.

Verification: Routes from CE-17 has been accepted by CE02 with same AS.
B 172.1.1.55 [20/0] via 172.16.2.1, 00:09:39
172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks

BGP Hijack


BGP – From Route Hijacking to RPKI: How Vulnerable is the Internet? by Mike Benjamin

BGP announcement for equal or more specific prefixes.
1. Equal prefixes (1.0.0.0/8)
2. Specific prefix (1.2.3.0/24)
BGP_Hijack
AS3 announce more specific prefixes to AS1 only, AS1(Victim) will forward it’s packet to AS3 (Attacker). Attacker can do payload injection, sniff packet etc.

Why do hijack happen?
1. Poor Hygeine (People do run their networks properly/Doesn’t clean things up)
2. Redistribution Mistakes
3. Typo’s
4. Malice
5. DDoS mitigation

What to stop Hijacking?
1. Prefix filtering
2. AS path filtering
3. Max prefix limits

Origin Validation Option
Method
RPKI – Full cryptographic trust towards ownership.
IRR (Legacy) – People register their autonomous system in a registry and put the prefixes you own.
Squatting – Who announce it yesterday.

Creating a baseline for hijack detection
1. Read one rib per day at random and record all as path. routeviews
2. Summarize each RIB entry to just origin AS uplink.
– Removing private ASNs and AS prepend
3. Baseline owner and uplink for 10entries in last 15days.

Detecting Hijack
Check for hijacks and record first match from:
1. Route matched owner
Tools:
a. Verify baseline from Oregon BGP data (comparison)
b. Current owner ex. show ip bgp 1.1.1.0/24 bestpath on public routers.
(verify bgp up/down time)
c. ASN lookup
2. Route and new origin AS match IRR record
3. New origin was an uplink in baseline data
4. New origin is a downlink of baseline owner
5. Remainder are assumed to be a real hijack

Fixing the problem
1. Start with origin validation
Resource Public Key Infrastructure (RPKI) – RFC6480
– Provides cryptographic proof of
ownership.
– RIRs provide the root trust
– Uses X.509 certificates for sub-
allocation
– Final owner signs a Route Origin
Authorization (ROA)
– ROA contains the prefix length
permitted and origin AS
2. Moving Path validation
3. BOGONS

What should people do?
1. Block Bogons -team-cymru.com/bogon-reference.html
2. What your routes – routeviews.org/
3. Adopt RPKI – nist.gov/programs-projects/robust-inter-domain-routing
4. BGP Security – datatracker.ietf.org/wg/sidr/about/
5. Encrypt your traffic

BGP security: an overview of the RPKI framework
https://www.noction.com/blog/bgp_security_rpki_overview

https://blog.thousandeyes.com/amazon-route-53-dns-and-bgp-hijack/