Download IP Network Configuration for Traffic Engineering

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts

Deep packet inspection wikipedia , lookup

IEEE 802.1aq wikipedia , lookup

Computer network wikipedia , lookup

Peering wikipedia , lookup

Recursive InterNetwork Architecture (RINA) wikipedia , lookup

List of wireless community networks by region wikipedia , lookup

Airborne Networking wikipedia , lookup

Network tap wikipedia , lookup

Multiprotocol Label Switching wikipedia , lookup

Zero-configuration networking wikipedia , lookup

Piggybacking (Internet access) wikipedia , lookup

IEEE 1355 wikipedia , lookup

Wake-on-LAN wikipedia , lookup

Cracking of wireless networks wikipedia , lookup

Transcript
IP Network Configuration
for Traffic Engineering
Anja Feldmann
Jennifer Rexford
AT&T Labs - Research
Presented by Zihui Ge
11/21/2000
Outline
Introduction
 Network model
 Router configuration
 Netdb examples
 Conclusion

Nightmare!
-Configure IP Router

Configuring IP routers is extremely
complicated






Diversity of network equipment
Large number of configuration options
Interaction of configuration parameters across
multiple routers
Rapid changes to network
Limited configuration tools
Severe consequences of error by manual
configuration of individual routers
HELP!
-An Abstract model

Need an ACCURATE network-wide
CONSISTENT ABSTRACT view of
network configuration.
Guide router configuration.
 Help in error detection.

What need to be modeled?

Physical components
• Routers, interfaces

Physical and logical connectivity
• Links, BGP sessions

Routing protocols
• Static routes, OSPF, BGP

Access control
• Packet filters, route filters
A peek on author’s model.
Object
Router
Attributes
router name, {loopback IP address}, location, {interface},
{global setting}
Interface router, interface name, {(IP address, IP prefix)}, capacity,
OSPF weight, queuing strategy, status (up/down), {access
list}, {static route}
IP prefix, link type (backbone/edge), OSPF area,
Link
{interface}
Access list IP prefix, permit/deny, {(interface, packet/route, in/out)}
Static route IP prefix, tag (administrative weight), {interface}
BGP
router, remote peer (IP address), remote AS, iBGP/eBGP,
{filter policy}, {interface},{session attribute}
Think about router.
Router




Typically consists of a route processor, a
switching fabric, a collection of interfaces.
Route processor construct forwarding table
based on information of intradomain and
interdomain routing protocol
Route processor is identified by loopback IP
addresses
Router name, {loopback IP address},
location, {interface}, {global setting}
Think about interface.


Position in the router(indicated by interface
name).
Each interface has a primary IP address and may
have one or more secondary IP addresses; each
IP address is associated with a particular prefix.



12.34.56.77 in prefix 12.34.56.76/30
Could associate with static routes , filters.
Router, interface name, {(IP address, IP
prefix)}, capacity, queuing strategy, status
(up/down),{access list}, {static route},OSPF
weight
Think about link.


Link is a physical media.
Addressing: IP prefix.




Ethernet or FDDI may have smaller mask length
Backbone link VS. edge link



12.34.56.76/30
Two ends 12.34.56.77 & 12.34.56.78
All interfaces in the same AS?
Participate in intradomain or interdomain routing?
IP prefix, link type (backbone/edge),{interface},
OSPF area
Think about OSPF.


Link state protocol.
OSPF routers exchange weight information and
compute shortest path



Extension for scalability:




Use flooding to propagate link-state update.
Length of path is defined as sum of weight
Routing hierarchy(OSPF areas)
Each link belongs to SAME OSPF area
Attribute “OSPF weight” in interface object
Attribute “OSPF area” in link object
Think about static route.

Provides a simple way to associate destination
prefixes with edge interfaces.



Advertise static route via OSPF or iBGP.


The router knows to direct packets destined to some
prefix to the appropriate next-hop interface.
Doesn’t ensure that the rest of the network knows how
to reach this destination prefix.
administrative weight
IP prefix, tag (administrative weight),{interface}
Think about BGP.
BGP






Distance Vector.
Filter policy contains import and export policies.
BGP object corresponds to one end point of a
BGP session(Addressing the session peer).
How to reach the remote end? (Interface)
Confederation, route reflectors?
router, remote peer (IP address), remote AS,
iBGP/eBGP, {filter policy}, {interface},{session
attribute}
Think about filter.

Packet filters
 firewall
 detect spoofed source IP address.
Route filter
 Custom-Provider
 avoids problem caused by misconfigured BGP
policies in downstream routers.

Access list


IP prefix, permit/deny, {(interface,packet/route,
in/out)}
Cool! We did it!
Object
Router
Attributes
router name, {loopback IP address}, location, {interface},
{global setting}
Interface router, interface name, {(IP address, IP prefix)}, capacity,
OSPF weight, queuing strategy, status (up/down), {access
list}, {static route}
IP prefix, link type (backbone/edge), OSPF area,
Link
{interface}
Access list IP prefix, permit/deny, {(interface, packet/route, in/out)}
Static route IP prefix, tag (administrative weight), {interface}
BGP
router, remote peer (IP address), remote AS, iBGP/eBGP,
{filter policy}, {interface},{session attribute}
Where to get information?
Potential Data Sources

SNMP MIBs
• Basic traffic statistics

Topology discovery tools
• traceroute, pathchar
• Active measure: topology, link capacity, …

Route monitoring
• Passive monitor: BGP, OSPF link state update

Router configuration files
• Physical and logical connectivity, link capacity,
routing protocols, access lists, …
Router Configuration Files

Cisco’s Internet Operating
System(ISO) serves as a de facto
standard for router configuration.

Access configuration files
Complete
 Consistent (snapshot)

A sample file
Dependencies Within a File

Domain(Section)-Independent

Referencing undefined items
• Undefined access-list, route-map, …
• Similar to compile error: undefined variable

Unused items
• Similar to compile warning: unused variable
Dependencies Within a File

Domain-Dependent

Inconsistent definitions
• “Speed” in channel-group
• “Bandwidth” in interface entry
• Missing “IP classless” will cause the router to
discard packets destined to an IP prefix that is not
aligned with octet boundaries.

Dependence on default parameters
• Missing OSPF area in the router section (router
won’t participate in OSPF)
• Missing OSPF weight in interface section (default
weight is set inversely proportional to capacity)
Dependencies Across Files

Inconsistent definitions

Router level Significance (will not cause
inconsistency)
• Similar to local variable
• For example: access-list

Network wide Significance (problematic)
• Similar to External variable or function
• A backbone link with interfaces on two routers: two
routers should agree on the selection of an OSPF
area.
Dependencies Across Files

Inconsistent references to remote
nodes(even worse)
eBGP session: peer router resides
outside backbone, on different
organization
 Two routers:

• Neighbor 10.1.2.3 remote-as 1
• Neighbor 10.1.2.3 remote-as 2
Netdb
Netdb is a Perl script that parses
configuration files in Cisco IOS
formation
 Populates the network model and
detects possible configuration errors
for AT&T Common IP Backbone.


Running time < 2 minutes
Netdb step 1
read configuration files of all routers
read keywords for global settings and
section names
forall routers {
identify section boundaries
parse global variables
check global variables
}
Netdb step 2
foreach section in (controllers, access lists,
interfaces, other filter sections, static routes,
OSPF, BGP) {
read section keywords
read customization input files
forall routers
parse section and check keywords,
network model violations
forall routers
perform error checks
}
STEP 2 - implementation

Multiple passes.
• Parse and load all file into memory

Strict sequence: Controllers < ..< BGP
•Earlier sections do not depend on later
sections
•Processing later section requests
previous section complete.
STEP 2 -What do we miss?
There is no LINK section in configuration
file!
 Link Object is created for the first
occurrence of a prefix in interface section,
and associated with the IP address of the
particular interface.
 It is extended to include the IP address of
other interfaces if the prefix reappears.

Netdb step 3
forall routers {
forall objects
report unassigned attributes
forall statements
report unused statements
}
Examples
Examples of netdb error messages
router1: unknown interface keyword: hold-queue value:
......
router2: ROUTE-MAP ERROR: community 1000
undefined ROUTEMAP1: community 1000 1010
router3: OSPF ERROR: ospf network 10.127.6.132/30
should either be in area 14 or 3
router4: OSPF ERROR: network: 10.126.212.0 0.0.0.3
area 2 with only one IP address 10.126.212.2
router5: OSPF ERROR: network: 10.126.12.172 0.0.0.3
area 3 with no IP address
router6: BGP ERROR: cannot resolve IP: 10.11.12.56
from ...BGP statement...
Examples-2
Error messages for policy violations.







router1: GLOBAL ERROR: missing parameter BGPCOMMUNITY
router2: GLOBAL ERROR: incorrect parameter CEF
value: ip cef
router3: ACL WARNING: default acl 6 missing
router3: ACL WARNING: default acl 7 differs from
specification: deny 172.0.0.0/8
router4: ACL ERROR: VPN customer needs in and out
ACL; (customer ABCDE)
router5: CONTROLLER ERROR: missing clock sync for
interface Serial2/1/0:2
router6: BGP ERROR: wrong rr definition for rr client
10.126.236.3 with peer-group abc
Conclusion
A network model for traffic
engineering
 A method to ensure network
consistency
 A tool, netdb, to identify
configuration errors

Thanks!
Happy
thanks giving!