Router Configuration Why we need to verify routerconfiguration - PowerPoint PPT Presentation

1 / 31
About This Presentation
Title:

Router Configuration Why we need to verify routerconfiguration

Description:

Loc Pref of NY link is higher. Inbound traffic. Use NY link unless it fails ... Use loc pref. For inbound traffic. For those routes which pass via AS 2, set ... – PowerPoint PPT presentation

Number of Views:44
Avg rating:3.0/5.0
Slides: 32
Provided by: vmw
Category:

less

Transcript and Presenter's Notes

Title: Router Configuration Why we need to verify routerconfiguration


1
Router Configuration--Why we need to verify
routerconfiguration
  • Prof. Gao
  • ECE697J Spring 2005
  • Advanced Computer Networks

2
Why verify router configuration?
  • Router Configuration
  • Typically done manually (prone to error)
  • Many parameters
  • Low level command language
  • Case Studies
  • BGP configuration for edge networks
  • BGP configuration for ISPs left for imagination

3
Dynamically Learned Defaults
  • RTA originates a default route 0.0.0.0/0 toward
    RTC only.
  • RTF will not get the default.

AS3
iBGP
172.16.20.2
172.16.1.1
RTA
RTF
provider
AS1
RTC
172.16.20.1
customer
4
Set default configuration
  • At Router A,
  • Router bgp 3
  • no synchronization
  • network 172.16.1.0 mask 255.255.255.0
  • neighbor 172.16.20.1 remote-as 1
  • neighbor 172.16.20.1 default-originate
  • (send default to RTC)
  • no auto-summary
  • The default-originate option of the neighbor
    router subcommand will cause 0/0 to be sent
    toward RTC.

5
Single homing
  • Customer connects to the Internet via a single
    connection to an ISP
  • Not necessary to run BGP
  • Customer usually can be served by pointing
    defaults towards the provider
  • Provider can install static route to reach the
    customer

Outgoing traffic
ISP
Customer
Incoming traffic
6
Single homing
  • Advantage
  • Least expensive and more effective
  • Reduce memory usage and processing overhead
  • Static default configuration
  • Disadvantage
  • Poor reliability

7
Multi-homing
  • Multi-homing Definition
  • More than one link external to the local network
  • Multi-homing Scenarios
  • Multi-homing to a single provider
  • Multi-homing to different providers
  • Customers of the same provider with a backup link
  • Customers of different providers with a backup
    link

8
Multi-homing to a single provider
  • Definition Two or more links to the same ISP
  • Case
  • Default only, one primary, and one backup

9
Example Default only, one primary, and one
backup (single provider)
  • AS1 provider
  • AS3 customer multi-homed to AS1
  • RTA running default toward AS1
  • NY link is primary
  • SF link is a backup if NY link fails

10
Routing Policies at RTA (AS3)
  • Outbound traffic
  • Use NY link unless it fails
  • Configuring two static routes in RTA pointing the
    defaults toward AS 1
  • Loc Pref of NY link is higher
  • Inbound traffic
  • Use NY link unless it fails
  • Send MED toward AS1 on both links with a lower
    metric on the NY link.
  • Prevent any BGP updates from coming into AS3
  • Configuring a route map or prefix list

11
RTA configuration
  • router bgp 3
  • network 172.16.220. 0 mask 255.255.255.0
  • neighbor 172.16.20.1 remote-as 1
  • neighbor 172.16.20.1 route-map BLOCK in
  • neighbor 172.16.20.1 route-map SETMETRIC1
    out (RTC)
  • neighbor 192.68.9.2 remote-as 1
  • neighbor 172.68.9.2 route-map BLOCK in
  • neighbor 172.68.9.2 route-map SETMETRIC2 out
    (RTD)
  • no auto-summary
  • ip route 0.0.0.0 0.0.0.0 172.16.20.1 50
    (RTC SF backup)
  • ip route 0.0.0.0 0.0.0.0 192.68.9.2 (RTD
    NY primary)
  • (NY link has higher preference, default 100)
  • route-map SETMETRIC1 permit 10 (RTC)
  • set metric 100
  • route-map SETMETRIC2 permit 10 (RTD)
  • set metric 50
  • ( routes sent to RTD with lower MED)
  • route-map BLOCK deny 10 (incoming BGP updates)

12
Multi-homing To Different ISP Providers
  • Definition Two or more links to different ISPs
  • Cases
  • Default, primary, and backup, plus full and
    partial routing

13
Default, primary and backup, Full/Partial Routing
  • AS 3 uses SF link to AS 1s local or customers
  • AS 3 use NY as primary link
  • AS 3 use SF as backup
  • Traffic to RTA goes through SF link
  • All others go through NY link

Internet
RTD
RTC
AS1
AS2
172.16.20.1
192.68.5.2
NY
SF
192.68.5.1
172.16.20.2
BGP
RTA
RTF
172.16.1.1
172.16.1.2
172.16.10.1
172.16.220.1
AS3
14
Routing Policies of AS 3
  • RTA
  • For outbound traffic, accepts
  • Routes originated from AS 1 or its customers
  • Default-route from AS 1
  • For inbound traffic,
  • Announces IP address block in RTF with AS prepend
  • RTF
  • For outbound traffic, accepts
  • All routes via NY link
  • For inbound traffic
  • Announces IP address block in RTA with AS prepend
  • AS3 cannot be a transit network from AS1 and AS2

15
RTA configuration (1)
  • router bgp 3
  • no synchronization
  • network 172.16.1.0 mask 255.255.255.0
  • network 172.16.10.0 mask 255.255.255.0
  • network 172.16.220.0 mask 255.255.255.0
  • neighbor 172.16.1.2 remote-as 3
  • neighbor 172.16.1.2 update-source Loopback0
  • neighbor 172.16.1.2 next-hop-self
  • neighbor 172.16.20.1 remote-as 1
  • neighbor 172.16.20.1 route-map ACCEPT_LOCAL in
  • neighbor 172.16.20.1 route-map PREPEND_PATH out
  • no auto-summary

16
RTA configuration (2)
  • ip as-path access-list 1 permit 1 ?0-9
  • ip as-path access-list 2 permit
  • (define routes originated from AS 1 and its
    customers)
  • access-list 1 permit 172.16.10.0 0.0.0.255
  • (define routes from RTF)
  • route-map PREPEND_PATH permit 10
  • match ip address 1
  • set as-path prepend 3
  • (AS prepend with routes from RTF, 3 is AS number)
  • route-map PREPEND_PATH permit 20
  • match as-path 2
  • route-map ACCEPT_LOCAL permit 10
  • match as-path 1
  • (Accept the routes of AS 1s local and its
    customers)

17
RTF configuration (1)
  • router bgp 3
  • no synchronization
  • network 172.16.1.0 mask 255.255.255.0
  • network 172.16.10.0 mask 255.255.255.0
  • network 172.16.220.0 mask 255.255.255.0
  • neighbor 172.16.1.1 remote-as 3
  • neighbor 172.16.1.1 next-hop-self
  • neighbor 192.68.5.2 remote-as 2
  • neighbor 192.68.5.2 route-map PREPEND_PATH out
  • no auto-summary

18
RTF configuration (2)
  • ip as-path access-list 2 permit
  • (routes originated from AS 3)
  • access-list 1 permit 172.16.220.0 0.0.0.255
  • (routes originated from RTA)
  • route-map PREPEND_PATH permit 10
  • match ip address 1
  • set as-path prepend 3
  • (AS prepend with routes from RTA, 3 is AS
    number)
  • route-map PREPEND_PATH permit 20
  • match as-path 2
  • (advertised as usual)

19
Customers of the same provider with a backup link
  • The private link can be used as a backup link
    when an Internet link fails
  • AS 3 is provider of AS 1 and AS 2
  • AS1 and AS 2 have a private link as backup

20
Backup Configuration
21
Routing Policies on RTC (AS 1)
  • AS3 offers services to AS1 and AS2
  • AS1 and AS2 have a private link as backup
  • For outbound, accepts
  • All routes from AS 3
  • All routes from AS 2, but less preferred
  • For inbound
  • Handle by default BGP behavior, shortest AS path

22
RTC configuration (customers of the same provider)
  • router bgp 1
  • network 192.68.11.0
  • neighbor 172.16.20.2 remote-as 3
  • neighbor 172.16.20.2 route-map PREF_FROM_AS3 in
  • neighbor 192.68.6.1 remote-as 2
  • neighbor 192.68.6.1 route-map PREF_FROM_AS2 in
  • no auto-summary

23
RTC configuration
  • ip as-path access-list 1 permit _2_
  • route-map PREF_FROM_AS3 permit 10
  • match as-path 1
  • set local-preference 100
  • (routes received from AS3, which match _2_,
  • have lowest loc_pref)
  • route-map PREF_FROM_AS3 permit 20
  • set local-preference 300 (all other updates)
  • (all other routes received from AS3 have highest
    loc_pref)
  • route-map PREF_FROM_AS2 permit 10
  • set local-preference 200
  • (routes from AS2 have loc_pref 200)

24
Customers of different providers with a backup
link
  • AS 1 and AS 2 have private link
  • AS 4 is provider of AS 1, AS 3 is provider of AS
    2
  • AS 3 connects to AS 4
  • AS 1 and AS 2 use providers as backup
  • The community approach
  • Dealing with adding and removing customers with
    dynamically setting the customers policies
  • The AS path manipulation approach
  • An alternative to the community approach

25
Example community approach (Customers of
different providers)
26
Routing Policies at RTC (AS 1)
  • For outbound traffic
  • Use loc pref
  • For inbound traffic
  • For those routes which pass via AS 2, set
    community to 440
  • Not announce routes originated from AS 3 to AS 4
  • Only announce routes originated from AS 1 and AS
    2
  • Definition on the usage of community at AS 4
  • 440 ---- set loc_pref to 40
  • Default ---- set loc_pref to 100

27
RTC configuration (AS 1)
  • router bgp 1
  • network 192.68.11.0 mask 255.255.255.0
  • neighbor 172.16.20.2 remote-as 4
  • neighbor 172.16.20.2 send-community
  • neighbor 172.16.20.2 route-map setcommunity out
  • neighbor 172.16.20.2 filter-list 10 out
  • neighbor 192.68.6.1 remote-as 2
  • no auto-summary

28
RTC configuration
  • ip as-path access-list 2 permit _2_
  • ip as-path access-list 10 permit
  • ip as-path access-list 10 permit 2
  • (Not announce routes originated from AS 3 to AS
    4)
  • route-map setcommunity permit 10
  • match as-path 2
  • setcommunity 440
  • (via AS2 match_2_, set community 40)
  • Route-map setcommunity permit 20 (do not have
    community set)

29
Router Configuration Commands
  • Syntax is vendor dependent
  • So far, all Cisco syntax,
  • Only a tip of iceberg
  • More details on Cisco command, see
  • http//www.cisco.com/univercd/cc/td/doc/product/so
    ftware/ios121/121cgcr/ip_c/ipcprt2/1cdbgp.htm

30
Summary
  • Configure for one router or peering session
  • More session for each router
  • Typically a large text file for each router
  • All for edge ASs so far
  • More complex for tier-1 providers
  • OSPF and BGP (iBGP and eBGP)
  • Each router has a long configuration (1000 lines)
    file!
  • Typically 100s of routers in an ISP
  • Routing policies can be complex
  • Assembly language like configuration language
  • High-level language is needed

31
Research Issues
  • Need of high-level language
  • Network-wide view (e.g., RPSL)
  • Reverse Engineering network-wide view
  • Construction from configuration files
  • Verification of static configuration
  • Correctness
  • Reachability
Write a Comment
User Comments (0)
About PowerShow.com