370 likes | 538 Views
Scaling and other new BGP Features Mark Turner Cisco Systems markt@cisco.com Queries: cs-iprouting-bgp@cisco.com Unless otherwise noted, these features are in 11.1(19)CC1 http://www.cisco.com/univercd/cc/td/doc/product/software/ios111/cc111. AGENDA - Behavioral Changes
E N D
Scaling and other new BGP Features Mark Turner Cisco Systems markt@cisco.com Queries: cs-iprouting-bgp@cisco.com Unless otherwise noted, these features are in 11.1(19)CC1 http://www.cisco.com/univercd/cc/td/doc/product/software/ios111/cc111
AGENDA - Behavioral Changes - Knobs for the “Common Good” - Knobs for fun and profit (reading exercise)
Behavioral Changes - Peer Groups - Route Reflectors - CPU/Memory utilization improvements
What: Remove restrictions on BGP peer groups Why: - Allow transit between EBGP peer- group members - Allow EBGP peer groups to span multiple LIS - Allow peer-group of Router Reflector Clients How: No knob
CORE Route Reflector Aggregation Router (RR Client) Client Peer Group Full Routes Peer Group “Default” Peer Group Customer Routes Peer Group - Use “neighbor default-originate” for per neighbor default
What:Remove RR client cross-cluster peering restrictions Why:Increase scalability/reliability of RR hierarchies How:No knob - extra decision criteria Notes:To avoid loops, ensure RR-RRC topology follows the physical topology
B (RRC) C (RRC) A (RR) D (RR) X X A and D choose EBGP path for X C is RRC of A - route to X is via B to A B is RRC of D - route to X is via C to D => Loop B<->C
Backbone Reflector relationships between Cluster C/Custer D and Cluster B now ok. RR RR RRC RRC RR RR Cluster A Cluster B RRC RR Cluster C RRC RR Cluster D
What: Remove 200 “network” command restriction Why: Customer demand. Limit now set by box resources (memory/nvram) How: No knob
Knobs for the “Common Good” - Prefix Counts/Overload - Prefix Lists - Overriding 3rd party NH - AS transition support - Conditional advertisements - CEF RPF - MAC Accounting
What: Prefix count and “overload protection” Why: - Some protection against peer “major mistakes”. - Consider applying to customer peer groups. How: neighbor <address/tag> maximum-prefix <n> [warning-only] Notes: - prefix count always shows up in “sh ip bgp sum” output - Small counting discrepancy - fix in 11.1(20)CC
Log output: %BGP-4-MAXPFS: No of prefix received from y.y.y.y reaches 0.75N, Max N %/BGP-4-MAXPFEXCEED: No of prefix received from y.y.y.y:N+x exceed limit N sh ip bgp output: 1.0.0.129 4 65000 37888 36523 113054 0 0 04:19:40 49938 1.0.0.129 4 65000 37992 36630 0 0 0 00:01:24 Idle (PfxCt)
sh ip bgp n 1.0.0.129 BGP neighbor is 1.0.0.129, remote AS 65000, external link Index 8, Offset 1, Mask 0x1 BGP version 4, remote router ID 0.0.0.0 BGP state = Idle, table version = 0 Last read 00:02:15, hold time is 180, keepalive interval is 60 seconds Neighbor NLRI negotiation: Configured for unicast routes only Minimum time between advertisement runs is 30 seconds Received 37992 messages, 0 notifications, 0 in queue Sent 36630 messages, 0 notifications, 0 in queue Connections established 2; dropped 2 Last reset 00:02:15, due to Peer exceeding maximum prefix limit Peer had exceeded the max. no. of prefixes configured. Reduce the no. of prefix and clear ip bgp 1.0.0.129 to restore peering No active TCP connection
What: Prefix lists Why: - Efficient handling of large route filters,eg atpeering points. - Incremental configuration updates - Filtering on prefix-length How: Prefix list definition: [no] ip prefix-list <list-name> [seq <seq-value>] deny | permit <network>/<len> [ge <ge-value>] [le <le-value>] Apply to Neighbor: neighbor <address/tag> prefix-list <list-name> in|out - can also be used with route-maps
Exact match • ip prefix-list aaa permit 35.0.0.0/8 • Prefix Length match • In 192/8, accept up to /24 • ip prefix-list aaa permit 192.0.0.0/8 le 24 • In 192/8, deny /25+ • ip prefix-list aaa deny 192.0.0.0/8 ge 25 • In all address space, deny /0 - /7 • ip prefix-list aaa deny 0.0.0.0/0 le 7
Notes: - prefix-list and distribute-list cannot be applied to single neighbor at the same time - Improvements to the CLI parser led to a ~4 times speed increase - which is just as well!!!!
What: Override inbound/outbound third-party NH Why: - Force neighbor to transit traffic at NAP - Set next-hop per prefix, based on route-map => more granularity than “neighbor x.x.x.x next-hop-self” How: route-map nukeNH permit 10 set ip next-hop <address> | peer-address
What: “OR” capability for peer AS number Why: Smooth transition between AS numbers (providers) for customers. How: remote-as xxx or yyy or zzz Caveats: Coming in 12.0 :-)
What: Conditional Advertisements Why: For dual homed sites - limit sub- provider CIDR block prefix announcements to failure condition only. (Yakov’s ‘96 Nanog talk) How: neighbor <address/tag> advertise-map <route-map> non-exist-map <route-map>
neighbor <R1> advertise-map amap non-exist-map backbone route-map amap permit 10 match ip address 1 route-map backbone permit 10 match ip address 2 access-list 1 permit 140.15.7.0 !Advertise this when... access-list 2 permit 140.15.0.0 !... this is not present. 24.10/16 140.15.7/24 (auto-injected) 140.15/16 ISP1 ISP2 R1 R3 24.10.6/24 140.15.7/24 R2 R4 140.15.7/24 24.10.6/24 24.10.6.14 140.15.7.4
What: RPF for CEF Why: Efficient protection against your customers sourcing ip spoof attacks How:global ip cef [distributed] Per interface interface xyz ip verify unicast reverse-path
Src IP 10.1.1.1 Src IP 20.1.1.1 RPF for CEF Customer Incoming packets S0 S1 To Internet 10/8 -> S0 20/8 -> S1 Router A’s routing table
What: MAC accounting: 512 addresses/direction. Why: eg NAP peer-flows without netflow analysis - USEFUL FOR DEBUGGING How: int fddi x ip accounting mac-address input ip accounting mac-address output Notes: 512 MAC entries; ip only; CEF/dCEF(11.1(20)CC only)/flow/optimum ethernet, fastethernet, fddi only SNMP Access http://www.cisco.com/public/mibs/supportlists/c7505/supportlist.html (look for CISCO-IP-STAT-MIB)
Example show output: sh int Ethernet0/1/3 mac Input (511 free) 0000.0c04.7ad5(167): 9 packets,1026 bytes, last: 20512ms ago Total: 9 packets, 1026 bytes Output (510 free) ffff.ffff.ffff(0 ): 16 packets, 960 bytes, last: 58108ms ago 0000.0c04.7ad5(167): 9 packets,1026 bytes, last: 21060ms ago Total: 25 packets, 1986 byte
Knobs for Fun and Profit - MBGP (BGP+) - Per neighbor bgp timers - Clear all peers in single AS - Always strip private AS - bgp logging - per neighbor timers, description, shutdown - community regexp match - bgp policy propagation - IP precedence accounting
What: Multicast NLRI support in BGP Why: Support incongruent multicast and unicast policy routing in the Internet How: ftp://ftpeng.cisco.com/ipmulticast/mbgp_deployment_overview.txt ftp://ftpeng.cisco.com/ipmulticast/mbgp_configuration_examples.txt ftp://ftpeng.cisco.com/ipmulticast/html/ipmulticast.html Notes: 11.1(20)CC only
What: Per neighbor bgp timers Why: Allow fast-fall over of specific peering sessions (eg for backup purposes) How: neighbor x.x.x.x times <keepalive> <holdtime>
What: A way to clear all sessions to a single AS Why: Operations How: clear ip bgp <AS number> Caveats: none known
What: A way to always strip private -AS Why: Allows pre-append of private-AS (before only adjacent private AS was stripped) How: neighbor <address/tag> remove-private-as always Caveats: none known
What: Neighbor/peer group description Why: Operational How: neighbor <address/tag> description <text>
What: Neighbor/peergroup shutdown command sho ip bgp sum: 1.0.0.1 4 1001 2810 353 0 0 0 00:00:02 Idle (Admin) Why: Remove need to cut-and-paste config in order to deactivate neighbor How: neighbor <addr>/<tag> shutdown
What: Regular expression match for communities Why: Community pattern matching in route-maps How: ip community-list <100-199> permit|deny regexp Notes: cisco regexp - not full perl/unix regexp!
What: Log neighbor up/down %BGP-5-RESET: neighbor 1.0.0.79 reset (Peer closing down the session) %BGP-5-ADJCHANGE: neighbor 1.0.0.131 Down %BGP-5-ADJCHANGE: neighbor 1.0.0.131 Up Why: Operational How: bgp log-neighbor-changes Caveats: none known
What: BGP policy propagation Why: Communicate QoS policy based on BGP attributes within and between ASs. How: - allows IP precedence or (11.1.20(CC) onwards) internal QoS Flag to be set based on AS list, community list, or IP address. Can then use CAR/WRED etc to enforce QoS policy. See: http://www.cisco.com/univercd/cc/td/doc/product/software/ios111/cc111/bgpprop.htm Notes: must enable CEF on interface
AS Path Example Set ip precedence to 3 for traffic from traffic originating in AS200 R1 R2 AS210 AS200 ! router bgp 210 table-map as-path-precedence-map neighbor “R1” remote-as 200 ! ip as-path access-list 101 permit $200^ ! route-map as-path-precedence-map match ip as-path 101 set precedence 3 ! interface hssi/0/0/0 bgp-policy ip-prec-map !
Unusual CAR Example - block traffic from community 100:0 to AS400 AS400 AS300 AS200 router bgp 200 table-map qos-class neighbor... ! ip community-list 100 permit ^100:0$ ! route-map as qos-class match community 100 set ip qos-group 2 ! “2” is the internal QoS classifier ! ! of which there are 100 ! interface serial 0/0/0 !outgoing interface to AS400 rate output qos 2 8000 8000 8000 conform drop exceed drop interface serial 0/0/1 !incoming interface from AS100 bgp-policy input ip-qos-class AS100
What: IP Precedence accounting (8 levels) sh int fddi 5/0/0 precedence Fddi5/0/0 Input Precedence 0: 439 packets, 39846 bytes Precedence 6: 10 packets, 745 bytes Output Precedence 6: 80 packets, 17302 bytes http://www.cisco.com/public/mibs/supportlists/c7505/supportlist.html CISCO-IP-STAT-MIB Why: non-netflow billing on precedence How: int fddi x ip precedence accounting input ip precedence accounting output Caveats: CEF/DCEF/Flow/Optimum only