Pete's Packet

Limitless

Archive for the ‘BGP’ Category

Mnemonic’s for BGP

Posted by Peter Kurdziel on August 13, 2009

Why laugh at me applying in out.

Weight  – apply inbound to influence outbound traffic.

local-pref – apply inbound to influence outbound traffic.

as-path – apply outbound to influence inbound traffic.

med – apply outbound to influence inbound traffic.

==========================================================

“We Love Oranges AS Oranges Mean Pure Refreshment”

W   Weight (Highest)
L   Local_Pref (Highest)
O   Originate (local originate)
AS  As_Path (shortest)
O   Origin Code (IGP < EGP < Incomplete)
M   MED (lowest)
P   Paths (External Paths preferred Over Internal)
R   Router ID (lowest)

================================================================

We – weight
Love – local preference
Algorithms – as-path
On – Origin
My – MED
Router – router-id

==============================================================

Discard all Worries before Leaving Rome As the Original Mis-information
Sound’s like a Neighbor’s Idea.

Discard = DISCARD unreachable next hop.
Worries= highest WEIGHT
Leaving=highest LOCALpreference
Rome=Originated on this ROUTER
As=shortest AS_PATH
Original=ORIGIN code
Mis-information=lowest MED
Sound=SOURCE (external or internal)
Neighbor’s=Closet IGP NEIGHBOR
Idea=lowest router ID

==============================

Filtering in BGP-

Request for Proposal – RFP

inbound

1. route-map
2. filter-list
3. prefix-list OR distribute-list

outbound is the opposite.
1. prefix-list OR distribute-list
2. filter-list
3. route-map

Posted in BGP, Routing & Switching Lab | 1 Comment »

Day 89 BGP notes

Posted by Peter Kurdziel on June 16, 2009

BGP notes

  1. BGP not working? Three things to look at:
    • EBGP-MULTIHOP (both sides)
    • UPDATE-SOURCE (loopback …)
    • NEXT-HOP-SELF (sho ip bgp x.x.x.x look for inaccessible)
  2. NEXT-HOP-SELF is used in unmeshed networks (fr) where BGP neighbors do no have a direct access to all other neighbors on the same subnet.
  3. redistributing ospf into BPG: (by default only EBGP routes are redistributed)
    • redistribute ospf 1 internal external route-map XX
  4. BGP Community attributes
    • internet – advertise to everyone
    • no export – advertise  to no ebgp peer
    • local as – advertise to the local as only = If you are using BGP confederations, local-as prevents the routes from traversing the sub ASes.  No-export allows the routes to go between sub-ASes in the confederation, but not to any other ASes outside of the confederration.
    • no advertise – advertise to no one
    • Community Description
      Local-AS Use in confederation scenarios to prevent sending packets outside the local autonomous system (AS).
      no-export Do not advertise to external BGP (eBGP) peers. Keep this route within an AS.
      no-advertise Do not advertise this route to any peer, internal or external.
      none Apply no community attribute when you want to clear the communities associated with a route.
      internet Advertise this route to the internet community, and any router that belongs to it.
  5. 200.0.0.1/32 = net 200.0.0.1 mask 255.255.255.255
  6. Use aggregate-address w/ summary-only to send a summary
  7. ^2004 = originated on AS200
  8. ^$ empty as path list
  9. Don’t see local info in sho ip bgp = typo
  10. When using loopbacks for peerings don’t forget ebgp-multihop and update-source
  11. troubleshooting: sh ip bpg , sho ip bgp XXX , sho ip bgp sum. Hop by hop.

Do internal BGP (iBGP) sessions modify the next hop?

A. iBGP sessions preserve the next hop attribute learned from eBGP peers. This is why it is important to have an internal route to the next hop. The BGP route is otherwise unreachable. In order to make sure you can reach the eBGP next hop, include the network that the next hop belongs to in the IGP or issue the next-hop-self neighbor command to force the router to advertise itself, rather than the external peer, as the next hop. Refer to the BGP Next Hop Attribute section of BGP Case Studies for a more detailed explanation.

This command is useful in unmeshed networks (such as Frame Relay or X.25) where BGP neighbors may not have direct access to all other neighbors on the same IP subnet.

More info on redistributing OSPF into BGP:

  1. router bgp 100
    1. redistribute ospf 1 match internal external 1 external 2
    2. !— This redistributes all OSPF routes into BGP.
  2. router bgp 100
    • redistribute ospf 1
    • !– This redistributes only OSPF intra- and inter-area routes into BGP.If you configure the redistribution of OSPF into BGP without keywords, by only OSPF intra-area and inter-area routes are redistributed into BGP, by default.
  3. redistribute ospf 1 match external 1 external 2
    • !— This redistributes ONLY OSPF External routes,
    • !— but both type-1 and type-2.
  4. redistribute ospf 1 match nssa-external 1 nssa-external 2
    • !— This redistributes only OSPF NSSA-external routes
    • !— Type-1 and Type-2 into BGP.

Posted in BGP, Routing & Switching Lab | Leave a Comment »

Troubleshooting BGP notes

Posted by Peter Kurdziel on May 18, 2009

Notes from Routing TC/IP

Troubleshooting BGP Neighbor Relationships

The following is the list of problems most commonly seen when forming BGP neighbor relationships.

  • Directly connected external BGP neighbors not initializing
  • Nondirectly connected external BGP neighbors not initializing
  • Internal BGP neighbors not initializing
    • The causes of this problem are identical to the previous problem of nondirectly connected external BGP neighbors not coming up:
      • The route to the nondirectly connected IBGP neighbor address is missing.
      • The update-source interface command is missing in BGP configuration.
  • BGP neighbors (external and internal) not initializing
    • Cause: Interface Access List Blocking BGP Packets

Troubleshooting BGP Route Advertisement /Origination and Receiving

The following is a list of problems discussed in this section related to BGP route originating and advertisement:

  • A BGP route not getting originated
    • Several causes in failure of BGP route origination exist, the most common of which are as follows:
      • The IP routing table does not have a matching route.
      • A configuration error has occurred.
      • BGP is autosummarizing to a classful/network boundary.
  • Problem in propagating/originating a BGP route to IBGP/EBGP neighbors
    • Cause: Misconfigured Filters
  • Problem in propagating a BGP route to an IBGP neighbor but not to an EBGP neighbor
    • Cause: BGP Route Was from Another IBGP Speaker
  • Problem in propagating an IBGP route to an IBGP/EBGP neighbor
    • Cause: IBGP Route Was Not Synchronized

Troubleshooting BGP Route Not Installing in Routing Table

Following is the list of all problems discussed in this section:

  • An IBGP-learned route is not getting installed in the IP routing table.
    • The most common causes of this problem are as follows:
      • IBGP routes are not synchronized.
      • The BGP next hop is not reachable.
  • An EBGP-learned route is not getting installed in the IP routing table.
    • The most common causes of EBGP routes not getting installed are as follows:
      • BGP routes are dampened.
      • The BGP next hop is not reachable in case of multihop EBGP.
      • The multiexit discriminator (MED) value is infinite.

Troubleshooting BGP Route-Reflection Issues

The most common problems in route-reflection networks are as follows:

  • Configuration mistakes
    • Cause: Failed to Configure IBGP Neighbor as a Route-Reflector Client
  • An extra BGP updated stored by a route-reflector client
    • Cause: Client-to-Client Reflection
  • Convergence time improvement for route reflectors and clients
    • Cause: Use of Peer Groups
  • Loss of redundancy between route reflectors and route-reflector clients
    • Cause: Cluster List Check in RR Drops Redundant Route from Other RR

Troubleshooting Outbound IP Traffic Flow Issues Because of BGP Policies

Here is the list of the most common problems encountered in managing outbound traffic flow:

  • Multiple exit points exist, but traffic goes out through one or a few exit routers.
    • Cause: BGP Policy Definition Causes Traffic to Exit from One Place
  • Traffic takes a different interface from what is shown in the routing table.
    • Cause: Next Hop of the Route Is Reachable Through Another Path
  • A multiple BGP connection exists to the same BGP neighbor, but traffic goes out through only one connection.
    • Cause: BGP Neighbor Is Influencing Outbound Traffic by Sending MED or Prepended AS_PATH
  • Asymmetrical routing occurs and it causes a problem especially when NAT and time-sensitive applications are used.
    • Cause: Outbound and Inbound Advertisement

Troubleshooting Load-Balancing Scenarios in Small BGP Networks

  • Problem: Load Balancing and Managing Outbound Traffic from a Single Router When Dual Homed to Same ISP
    • Cause: BGP Installs Only One Best Path in the Routing Table
    • Problem: Load Balancing and Managing Outbound Traffic in an IBGP Network
      • Cause: By Default, IBGP in Cisco IOS Software Allows Only a Single Path to Get Installed in the Routing Table Even Though Multiple Equal BGP Paths Exist

Troubleshooting Inbound IP Traffic Flow Issues Because of BGP Policies

Some of the most common problems in managing inbound IP traffic in an AS using BGP are as follows:

  • Multiple connections exist to an AS, but all the traffic comes in through one BGP neighbor, X, in the same AS.
    • Cause: Either BGP Neighbor at X Has a BGP Policy Configured to Make Itself Preferred over the Other Peering Points, or the Networks Are Advertised to Attract Traffic from Only X
  • A BGP neighbor in AS 110 should just be a backup provider, but some traffic from Internet still comes through AS 110.
    • Cause: Route Advertisements for 100.100.100.0/24 in AS 109 Attract Internet Traffic Through That BGP Neighbor in AS 110
  • Asymmetrical routing occurs.
  • Traffic to a certain subnet should come through a particular connection, but it is coming from somewhere else.

Troubleshooting BGP Best-Path Calculation Issues

The following are the cases discussed in this section:

  • When the router ID (RID) selects the best path, BGP does not always select the lowest RID path as best, as described in the best-path algorithm.
  • Two BGP neighbors in the same AS advertise a different MED for the same prefix, but the lowest MED is not selected as best, as described in the best-path algorithm.

Troubleshooting BGP Filtering

Problem: Standard Access List Fails to Capture Subnets

  • Use extended access lists or prefix lists that support proper mask check of routes when received in BGP.

Problem: Extended Access Lists Fails to Capture the Correct Masked Route

  • Use an extended access list.
  • Use a prefix list.

Problem: AS_PATH Filtering Using Regular Expressions

Posted in BGP, Real World, Routing & Switching Lab | Leave a Comment »

Day 122 I reread “routing TCP/IP Vol 2′s” bgp section.

Posted by Peter Kurdziel on May 14, 2009

Day 122 – I reread “routing TCP/IP Vol 2′s” bgp section.
maximum-paths – changes the default number of parallel paths from 1 t o6.

keepalive default is 60 seconds , holdtime 180 seconds

you can write the as # two way was router bgp 111 or router bgp 111.111

aa:nn = as / community #
ex as 625 community value 70
625:70 convert to hex
625= 271 or 0×0271
70= 46 or 0×0046
now cisco’s community values use decimal
so 02710046 is 40960070 in decimal aka 625:70

Internet – no community value
NO_EXPORT – community value 4294967041 or 0xffffff01- not advertised to EBP of outside of a confederation
NO_ADVERTISE – community value 4294967042 or 0xffffff02 -not advertised to anyone.
LOCAL_AS – community value 4294967043 or 0xffffff03 -not advertised to EBGP, including peers in other AS’s within a confederation.

path
highest weight
highest local-pref
locally originated route
shortest as-path
lowest origin code IBPG vs EBGP vs incomplete
lowest MED
Prefer EBGP routers over confederation EBGP routes and prefer confederation EBGP routes over IBGP routes
shortest path to the next_hop
if maximum-paths is enabled install all equal cost paths into the Loc_RIB
if multipath is not enabled, prefer the route with the lowest BGP router ID

Community Description
Local-AS Use in confederation scenarios to prevent sending packets outside the local autonomous system (AS).
no-export Do not advertise to external BGP (eBGP) peers. Keep this route within an AS.
no-advertise Do not advertise this route to any peer, internal or external.
none Apply no community attribute when you want to clear the communities associated with a route.
internet Advertise this route to the internet community, and any router that belongs to it.

rule of synchronization
routes learned by IBGP must also be in the IGP routing table. Synchronization prevents packets from being black holed by the transit AS because the IGP does not have the route.
With a full mesh synchronization stands in the way because all IBGP routers know about the route anyway and are using an IGP for BGP connectivity vs advertising the route via an IGP.

Tools for large scale BGP
peer groups – apply policies to a group of routers
communities – apply policies to a group of routes
route reflectors
confederations

RR rules
1. if a route was learned from a nonclient IBGP peer, it’s reflected to clients only.
2. if a route was learned from a client, it’s reflected to clients and non clients.
3. if a route was learned from an EBGP peer, it’s reflected to clients and non clients.

I am moving on to complete the BGP labs  I wanted to review yesterday.

Lab 11 task 6 =For ORF, don’t forget to config ADDRESS-FAMILY IPV4 UNICAST !!!!!!!!!!

Posted in BGP, Routing & Switching Lab | Leave a Comment »

Day 123 Narbik BGP lab review

Posted by Peter Kurdziel on May 13, 2009

I want to do these labs again:

Lab 6 task 8 – community attributes

Lab 9 task 3

Lab 11 task 6

Lab 12

Lab 13 task 6

Short day today due to other obligations.

Posted in BGP, Routing & Switching Lab | Leave a Comment »

Day 123 Narbik BGP lab 15

Posted by Peter Kurdziel on May 13, 2009

lab 15 -  BGP confederations

Group AS’s in a single as.

BGP confederation identifier #

BGP confederation peers {as#/s}

R1, R2, R3 & R4 and part of confederation 100

r1 (as65511) ……r2 (as65522)……..r3 (as65534)…….r4 (as65534)……r5(as500)

On R1, R2, R3  you need BGP confederation identifier 100 & BGP confederation peers {as#/s}. But in R4 you only need BGP confederation identifier 10 since R4 is in the same AS as R3.

Posted in BGP, Routing & Switching Lab | Leave a Comment »

Day 125 – Narbik BGP labs 7,8,9, & 10

Posted by Peter Kurdziel on May 11, 2009

lab 7, 8, 9 & 10

Here is a something I use to remember this:
Why laugh at me going in to go out.

Weight – apply inbound to influence outbound
Local-pref – apply inbound to influence outbound
As-path – apply outbound to influence inbound
MED – apply outbound to influence inbound

weight is local to the router only it’s not advertised anywhere. higher is better.

local-pref is used to prefer an exit point from the local AS. Local-pref is propagated throughout the local AS. higher is better.

as-path is used to influence another AS. shorter is beter. There is a good exmaple in routing TCP/IP vol 2 pages 252-256

MED – used a sugestion to an external AS regarding the perferred route. higher attributes over ride MED. Lower is better.
MED is compared for the same AS only. to Change this use bgp always-compare-med.
Use bgp bestpath as-path ignore (hidden command) to basically ignore the previous attributes and use the MED.
Here is an example after enabling those 2 commands:
Network          Next Hop            Metric LocPrf Weight Path
*> 1.0.0.0          0.0.0.0                  0         32768 i
*  2.0.0.0          10.1.12.2              120             0 200 i
*>                  10.1.14.4              100             0 400 300 200 i
*  22.0.0.0         10.1.12.2              120             0 200 i
*>                  10.1.14.4              100             0 400 300 200 i
Here the best path is ignored (shorter as path length) and the MED is used.

bgp bestpath med missing-as-worst – any path with a missing MED becomes the worst path.
before:
Network          Next Hop            Metric LocPrf Weight Path
*> 33.0.0.0         10.1.12.2                              0 200 300 i

after:
*                   10.1.12.2       4294967295             0 200 300 i

Posted in BGP, Routing & Switching Lab | Leave a Comment »

Day 125 notes – Narbik BGP lab 6

Posted by Peter Kurdziel on May 11, 2009

notes from Narkib’s BGP lab 6 – Community Attributes

  • community attributes

internet – advertise to everyone
no export – advertise  to no ebgp peer
local as – advertise to the local as only
no advertise – advertise to no one

Community Description
Local-AS Use in confederation scenarios to prevent sending packets outside the local autonomous system (AS).
no-export Do not advertise to external BGP (eBGP) peers. Keep this route within an AS.
no-advertise Do not advertise this route to any peer, internal or external.
none Apply no community attribute when you want to clear the communities associated with a route.
internet Advertise this route to the internet community, and any router that belongs to it.
  • you can apply these per neighbor or per network.
  • You can tag routes with a community on one router and filter communities with a community-list on another router.

eg. r1 uses AS200 to reach 20.1.2.0/24 and 30.1.2.0/24 and  r1 uses AS300 for 20.1.3.0/24 and 30.1.3.0/24

r2—–r1—-r3  r1 is the hub

Config r2 and r3 first to tag the routes

r2
access-list 2 permit 20.1.2.0 0.0.0.255
access-list 3 permit 20.1.3.0 0.0.0.255

route-map TEST permit 10
match ip address 2
set community 2
!
route-map TEST permit 20
match ip address 3
set community 3
!
route-map TEST permit 30

router bgp 200
no synchronization
bgp log-neighbor-changes
network 20.1.2.0 mask 255.255.255.0
network 20.1.3.0 mask 255.255.255.0
neighbor 10.1.12.1 remote-as 100
neighbor 10.1.12.1 send-community
neighbor 10.1.12.1 route-map TEST out
no auto-summary

r3
access-list 2 permit 30.1.2.0 0.0.0.255
access-list 3 permit 30.1.3.0 0.0.0.255
!
route-map TEST permit 10
match ip address 2
set community 2
!
route-map TEST permit 20
match ip address 3
set community 3
!
route-map TEST permit 30

router bgp 300
no synchronization
bgp log-neighbor-changes
network 30.1.2.0 mask 255.255.255.0
network 30.1.3.0 mask 255.255.255.0
neighbor 10.1.13.1 remote-as 100
neighbor 10.1.13.1 send-community
neighbor 10.1.13.1 route-map TEST out
no auto-summary

Now you can configure r1 to filter the communities
r1
ip community-list standard TAG2 permit 2
ip community-list standard TAG3 permit 3

route-map TEST permit 10
match community TAG2
set ip next-hop 10.1.12.2
!
route-map TEST permit 20
match community TAG3
set ip next-hop 10.1.13.3
!
route-map TEST permit 30

router bgp 100
no synchronization
bgp log-neighbor-changes
network 1.0.0.0
neighbor 10.1.12.2 remote-as 200
neighbor 10.1.12.2 send-community
neighbor 10.1.12.2 route-map TEST in
neighbor 10.1.13.3 remote-as 300
neighbor 10.1.13.3 send-community
neighbor 10.1.13.3 route-map TEST in
no auto-summary
R1(config-router)#do sho ip bg
BGP table version is 8, 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

Network          Next Hop            Metric LocPrf Weight Path
*> 1.0.0.0          0.0.0.0                  0         32768 i
*> 20.1.2.0/24      10.1.12.2                0             0 200 i  <—– x.x.2.0 uses 10.1.12.2 ( r2)
*> 20.1.3.0/24      10.1.13.3                0             0 200 i <—– x.x.3.0 uses 10.1.13.3 ( r3)
*> 30.1.2.0/24      10.1.12.2                0             0 300 i <—– x.x.2.0 uses 10.1.12.2 ( r2)
*> 30.1.3.0/24      10.1.13.3                0             0 300 i <—– x.x.3.0 uses 10.1.13.3 ( r3)

Posted in BGP, Routing & Switching Lab | Leave a Comment »

Day 127

Posted by Peter Kurdziel on May 9, 2009

Day 127 – Saturday – study hours: 2 hours and 20 min. Topics: Narbiks BGP lab 5 & 6.

My biggest time wasters are checking email and getting side tracked on the internet.

** when changing the bgp dampening half-life parameter make sure you manually enter the reuse, supperss and max-suppress-time.

^300$ matches everything originated by AS 300 or another way to say this is that ^300$ matches al lexisting and futire prefixes from AS 300.

3 way to advertise a more specific route:
1 acl deny / route-map permit / aggregate-address suppress-map
2 acl per / route-map deny / suppress-map
3 acl per / route-map per / neighbor unsuppress-map

Posted in BGP, Routing & Switching Lab | 2 Comments »

BGP: regular expression

Posted by Peter Kurdziel on April 7, 2009

filter networks that originated in AS 300

ip as-path access-list 1 deny _300$
ip as-path access-list 1 permit .*
!
router bgp 100
neighbor 10.1.12.2 filter-list 1 in

filter networks that traveresed through AS 300

ip as-path access-list 1 deny _300_
ip as-path access-list 1 permit .*
!
router bgp 100
neighbor 10.1.12.2 filter-list 1 in

filter networks that originated in AS 300

ip as-path access-list 1 deny ^$
ip as-path access-list 1 permit .*

neighbor 10.1.23.2 filter-list 1 out

filter networks from neigboring AS 200

ip as-path access-list 1 deny _200_300$
ip as-path access-list 1 permit .*
!
ip as-path access-list  1 deny ^200$
ip as-path access-list  1 per .*

filter all prefixes from my directly connected neighbors

ip as-path acc 1 deny ^[0-9]+$
ip as-path acc 1 per .*

filter all prefixes that originated in AS 300 and traversed through AS 200
ip as-path access-list 1 deny _200_300$
ip as-path access-list 1 permit .*

Posted in BGP, Routing & Switching Lab | Leave a Comment »

 
Follow

Get every new post delivered to your Inbox.