1 / 35

BGP Implementation

BGP Implementation. IBGP and EBGP. IBGP sessions established within an AS Usually use loopback addresses—IGP path redundancy IBGP sessions cannot relay IBGP-received routing information Full mesh of IBGP sessions in ISP environment

bgass
Download Presentation

BGP Implementation

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. BGP Implementation

  2. IBGP and EBGP • IBGP sessions established within an AS • Usually use loopback addresses—IGP path redundancy • IBGP sessions cannot relay IBGP-received routing information • Full mesh of IBGP sessions in ISP environment • Can use scaling mechanisms such as route reflection and confederations • EBGP sessions established across an AS boundary • Usually use physical interfaces—IP TTL is 1 by default • BGP next hop does not change on IBGP by default • Watch out for BGP next-hop reachability problems • You can use NHS policy or IGP passive on AS external interface

  3. 4-Byte AS Number Concepts • Minimal changes in BGP operations • Specified in RFC 4893 and implemented using a new capability 65 • Two new optional transitive attributes: AS4_PATH and AS4_AGGREGATOR • New extended community attributes: 4-byte AS specific • Compatibility • 32-bit mode when peering with 32-bit peers • 16-bit mode when peering with 16-bit peers • AS 23456 (AS_TRANS) is used as the AS number when a 4-byte AS number must be represented on a router that does not understand it

  4. 4-Byte AS Number Compatibility Example AS4_PATH: 110000 100000 AS_PATH: 23456 23456 AS4_PATH: 110000 100000 AS_PATH: 65000 23456 23456 AS_PATH: 100000 AS 100000 AS 110000 AS 65000 AS 120000 Peers with AS 23456 AS 120000 reconstructs the AS_PATH AS_PATH: 65000 110000 100000

  5. Connecting IPv6 Sites Through an IPv4 Core • 6PE is a technique that provides interconnection of IPv6 sites over an IPv4 MPLS cloud (RFC 4798) • ISP core runs IPv4 and MPLS • PEs are dual-stack routers running IPv6 towards an IPv6 island and IPv4 towards the core • PEs convey family IPv6 labeled unicast between them over IPv4 BGP sessions • P routers are not aware of IPv6, they forward MPLS packets • You must configure appropriate export policies on the PE router to share route information between BGP and other protocols LSP IPv6 IPv6 IPv4 MPLS 6PE 6PE IPv4 IBGP PE1 PE2

  6. Additional 6PE Details • Next hop self policy is not required on 6PE routers • Advertising PE router automatically sets BGP next hop attribute to IPv4-mapped IPv6 address (RFC 3513) • Receiving PE automatically puts IPv4-mapped IPv6 addresses into inet6.3 table when MPLS LSPs are set up

  7. Dual Stack Peering Caveats • MP-BGP requires that a BGP next hop use the same address family as the NLRI • When IPv4 session is used to convey IPv6 routes, BGP next hop is encoded in IPv4-compatible IPv6 address (RFC 3513) • Make sure that this address is configured and reachable • If IPv6 peering uses link local addresses (FE80::/10), local interface configuration is required

  8. BGP Authentication • BGP exchanges can be authenticated • By default, authentication is disabled • You can configure MD5 authentication key or • You can configure hitless authentication key rollover • Allows update authentication keys without resetting any BGP peering sessions • Allows you to choose the authentication algorithm • Authentication can be configured under BGP protocol, group, or neighbor level

  9. BGP Load Balancing • Default load balancing • For IBGP, BGP uses per prefix load balancing • If multiple prefixes received from the same preferred peer and IGP ECMP exists to the peer • For EBGP, BGP algorithm selects exactly one active path (no load balancing) • Multihop can be used with EBGP • Establishes sessions with peers that are more than one hop away • Required for loopback EBGP peering • Over-one-session per prefix balancing, similar to IBGP with IGP ECMP • Multipath is used mostly with EBGP for load balancing • Over-many-sessions per prefix balancing (Up to 16 paths)

  10. IBGP Scaling Using Route Reflection • Route reflection notes • Defined in RFC 4456 • Allows route reflector to re-advertise IBGP-learned route to another IBGP speaker • RR does not change existing BGP attributes • Adds two extra BGP attributes to prevent loops • Cluster list • Originator ID • IBGP peers of an RR are divided into two groups: • Clients • Non-clients

  11. IBGP Scaling Using Confederations • Confederation notes • Defined in RFC 3065 • Breaks an AS (confederation) into multiple sub-ASs • Within each sub-AS: • Use a private AS number • An IBGP full-mesh topology is required • Between sub-ASs: • EBGP-type (CBGP) sessions are required • Only the AS path attribute is changed • Prevents loops in the network • Sub-AS numbers are not used when comparing AS path lengths • Other BGP attributes are not modified by default

  12. BGP Implementation Time-Savers • Before you begin configuring: • Read all tasks in the section carefully • Plan your strategy for all tasks • Resist the keyboard • Draw out the RR or confederation topology on a map • Keep in mind requirements for redundant connectivity • Decompose the IPv4 and IPv6 tasks • Think of efficient grouping of BGP peers • Global, group, or neighbor • Simplify configuration steps • Cut and paste commands using the command show | display set • Copy and paste with an offline text editor

  13. Attribute Manipulation with Policy • You can change any of these BGP attributes with a routing policy then action: • Next hop • Local preference • Origin • MED • AS path • Community

  14. Modifying BGP Attributes • Reasons for modifying BGP attributes: • Setting next hop to self can resolve hidden EBGP routes for other IBGP neighbors • Changing local preference can influence AS outbound traffic • Changing origin can negatively influence routing decisions • Setting MED can influence the AS inbound traffic when the local AS has multiple links with a neighboring AS • Prepending or expanding AS number can negatively influence the AS inbound traffic

  15. Attribute Manipulation without Policy • You can change some BGP attributes by applying settings directly to BGP protocol, group, or neighbor level • as-override (AS path) • remove-private (AS path) • metric-out (MED) • local-preference (local preference)

  16. Community Types • Regular community • 2-byte-as-number:assigned-number (65003:1111) • Well-known communities • no-export (0xFFFFFF01) • no-advertise (0xFFFFFF02) • no-export-subconfed (0xFFFFFF03) • Extended community • type:administrator:assigned-number • 2-byte AS specific • 4-byte AS specific • IPv4 address specific • IPv6 address specific

  17. Community Tag and Removal • You can set, add, and delete communities with a policy then action • set overrides the community list with a new list • add adds a new community list to the existing list • delete removes communities matching configured pattern from the existing list • You can use regex in the community definition

  18. Using Regular Expressions • Using regex simplifies tasks and outputs • Implement in AS path matching policies • Define the as-path option with the regex criteria • Use the defined as-path in a policy • Utilize in community matching policies • Use simple or complex regex definitions • Use with show commands • Simplifies outputs based on the regex definition

  19. Remote Triggered Black Hole Concept • RTBH is a technique for the mitigation of DoS attacks (RFC 5635) • Used by ISPs to protect their customers • Firewall filters (ACLs) can do the same • But RTBH is more efficient • Two types of RTBH: • Destination-based filtering • Source-based filtering • Works in combination with unicast RPF • More flexible than destination-based filtering

  20. RTBH Sample Topology AS 200 AS 300 route D, NH = discard Policy: from community RTBH then NH = D uRPF uRPF R1 R2 DoS attack source = A destination = B route A, community = RTBH Trigger router AS 65000 R3 DoS attack reported AS 100 Customer

  21. RTBH Example Configuration (1 of 2) • Trigger router [edit routing-options] user@R3# show static { route 10.100.1.1/32 { tag 666; reject; } } [edit policy-options] user@R3# show policy-statement TRIGGER { term 1 { from { protocol static; tag 666; } then { local-preference 200; community set RTBH; community add no-export; accept; } } } community RTBH members 100:666; community no-export members no-export; [edit protocols bgp] user@R3# show group IBGP { type internal; local-address 192.168.100.3; export TRIGGER; neighbor 192.168.100.10; }

  22. RTBH Example Configuration (2 of 2) • Filtering router [edit interfaces ge-0/0/1] user@R1# show unit 0 { family inet { rpf-check; address 10.11.12.1/24; } } [edit routing-options] user@R1# show forwarding-table { unicast-reverse-path feasible-paths; } [edit policy-options] user@R1# show policy-statement BLACK-HOLE-FILTER { from { protocol bgp; as-path LOCAL-AS; community RTBH; } then { next-hop discard; } } community RTBH members 100:666; as-path LOCAL-AS "()"; [edit protocols bgp] user@R1# show group IBGP { type internal; local-address 192.168.100.1; import BLACK-HOLE-FILTER; neighbor 192.168.100.10; }

  23. BGP Policy Pitfalls • Policy creation • Term order is important • Understand the default BGP routing policy • Applying policies • Ensure you apply the policy • Directionality is important • Import or export • Policy application order is important

  24. BGP Policy Time-Savers • Before you begin configuring: • Read all tasks in the section carefully • Plan your strategy for all policy tasks • Resist the keyboard • Identify tasks that can be combined into a single policy • Identify which policies need to be applied on each router • Simplify configuration steps • Reuse policies when possible • Cut and paste commands using the show | display set command • Copy and paste with an offline text editor

  25. Task and Topology Core BGP Network • Task: • Routes received from the Provider router should not be advertised to the Transit-1 router or vice versa. AS 200 C-1 P1 Provider AS 100 Loopbacks R1 – 192.168.1.1 R2 – 192.168.1.2 R3 – 192.168.1.3 R4 – 192.168.1.4 Customer-1 AS 700 R1 R2 150.150.0/16 200.200.0/16 T-1 Transit-1 AS 500 R4 R3 100.100.0/16

  26. What Now? • What are the required components? • Connectivity • IBGP neighbors must be established • EBGP neighbors must be established • IBGP core must be learning routes from EBGP neighbors • External routes must be active in IBGP core • Next hop self policy or external interface in IGP passive • Unique community must be created for all external peers • Import policies must be created and applied to tag each external peer’s routes with a unique community • Export policy must be applied to the appropriate EBGP peering to reject routes tagged with the defined community

  27. Task Completion (1 of 6) • Step 1: Initial neighborship verification • Verify connectivity R1 lab@R1> show bgp summary Groups: 2 Peers: 4 Down peers: 0 Table Tot Paths Act Paths Suppressed History Damp State Pending inet.0 30 30 0 0 0 0 inet6.0 0 0 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped... 172.27.0.30 100 280 283 0 0 2:06:39 10/10/10/0 0/0/0/0 192.168.1.2 200 406 406 0 0 3:02:54 10/10/10/0 0/0/0/0 192.168.1.3 200 385 385 0 0 2:53:17 10/10/10/0 0/0/0/0 192.168.1.4 200 369 368 0 0 2:46:06 0/0/0/0 0/0/0/0 /1.0

  28. Task Completion (2 of 6) • Step 2: Route verification • Verify external routes on R1 lab@R1> show route 100.100/16 inet.0: 48 destinations, 48 routes (48 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 100.100.0.0/24 *[BGP/170] 02:04:05, localpref 100, from 192.168.1.3 AS path: 500 I > to 172.27.0.13 via ge-0/0/6.0 ... lab@R1> show route 150.150/16 inet.0: 48 destinations, 48 routes (48 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 150.150.0.0/24 *[BGP/170] 02:12:30, localpref 100 AS path: 100 I > to 172.27.0.30 via ge-0/0/1.0 ... lab@R1> show route 200.200/16 inet.0: 48 destinations, 48 routes (48 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 200.200.0.0/24 *[BGP/170] 02:09:23, localpref 100, from 192.168.1.2 AS path: 700 I > to 172.27.0.2 via ge-0/0/3.0 ...

  29. Task Completion (3 of 6) • Step 3: Define communities • Configure communities on R1 • Define the same communities on the other two ASBR routers (R2 and R3) • To save time use copy and past to simplify this task [edit policy-options] lab@R1# set community p-routes members 200:150 [edit policy-options] lab@R1# set community c1-routes members 200:700 [edit policy-options] lab@R1# set community t1-routes members 200:500

  30. Task Completion (4 of 6) • Step 4: Define import policies • Configure import policy on R1 • Create similar import policies on the other two ASBR routers (R2 and R3) to tag the incoming routes [edit policy-options policy-statement from-P] lab@R1# set term 1 from neighbor 172.27.0.30 [edit policy-options policy-statement from-P] lab@R1# set term 1 then community add p-routes [edit policy-options policy-statement from-P] lab@R1# set term 1 then accept [edit policy-options policy-statement from-P] lab@R1# show term 1 { from neighbor 172.27.0.30; then { community add p-routes; accept; } }

  31. Task Completion (5 of 6) • Step 5: Define export policies • Configure an export policy on R1 to reject Transit-1 routes • Create a similar export policies on R3 to reject Provider routes [edit policy-options policy-statement to-P] lab@R1# set term 1 from protocol bgp [edit policy-options policy-statement to-P] lab@R1# set term 1 from community t1-routes [edit policy-options policy-statement to-P] lab@R1# set term 1 then reject [edit policy-options policy-statement to-P] lab@R1# show term 1 { from { protocol bgp; community t1-routes; } then reject; }

  32. Task Completion (6 of 6) • Step 6: Apply import and export policies to the EBGP sessions • Apply the export and import policy on R1 • Apply the import policies to the other two ASBR’s EBGP sessions • Remember to apply the export policy on R3’s EBGP session to the Transit-1 router [edit protocols bgp] lab@R1# set group Provider import from-P [edit protocols bgp] lab@R1# set group Provider export to-P [edit protocols bgp] lab@R1# show group Provider type external; import from-P; export to-P; peer-as 100; neighbor 172.27.0.30;

  33. Task Verification (1 of 2) • Export policy verification on R1 to Provider lab@R1> show route advertising-protocol bgp 172.27.0.30 inet.0: 48 destinations, 48 routes (48 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 200.200.0.0/24 Self 700 I * 200.200.1.0/24 Self 700 I * 200.200.2.0/24 Self 700 I * 200.200.3.0/24 Self 700 I * 200.200.4.0/24 Self 700 I * 200.200.5.0/24 Self 700 I * 200.200.6.0/24 Self 700 I * 200.200.7.0/24 Self 700 I * 200.200.8.0/24 Self 700 I * 200.200.9.0/24 Self 700 I

  34. Task Verification (2 of 2) • Export policy verification on R3 to Transit-1 lab@R3> show route advertising-protocol bgp 172.27.0.58 inet.0: 47 destinations, 47 routes (47 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 200.200.0.0/24 Self 700 I * 200.200.1.0/24 Self 700 I * 200.200.2.0/24 Self 700 I * 200.200.3.0/24 Self 700 I * 200.200.4.0/24 Self 700 I * 200.200.5.0/24 Self 700 I * 200.200.6.0/24 Self 700 I * 200.200.7.0/24 Self 700 I * 200.200.8.0/24 Self 700 I * 200.200.9.0/24 Self 700 I

More Related