Journey Complete - CCIE # 28547

The Journey was completed and another one began on March 31, 2011

INE OLS - PFR COMPONENT SETUP

INSTRUCTOR -  ANTHONY SEQUEIRA


OVERVIEW

• Focus here is on MC and one or more BRs

______________________________________________________________
REVIEW

• MC is the BRAINS of the operation.
• BRs connect to ISP or WAN exit points.
• MD5 PROTECTS MC to BR communication.
• SEPARATE protocol exits for their communication.
• SEPARATE from ALL other routing traffic.
• EACH BR must have an EXTERNAL interface and an INTERNAL interface.

_____________________________________________________________
PRE-REQUISITES

• CEF on ALL routers.
• Routing protocol or static routing in place.
• IPSEC or GRE VPN support ONLY.
• MULTIPLE BRs MUST see next-hops in DIFFERENT subnets.
• BRs communicating with MULTIPLE providers over BC media are NOT supported.
• Exclude inbound MC source address from PfR control.
• TOKEN RING IS NOT SUPPORTED.

______________________________________________________________
MASTER CONTROLLER

• How much does MC do in a network?
• Function of available memory.
• NOT in traffic path , but it MUST have EFFICIENT access to BRs.
• Up to 10 BRs with up to 20 EXTERNAL interfaces are supported.

_____________________________________________________________

BORDER ROUTER

• This is a device IN TRANSIT PATH.
• Known as POLICY ENFORCEMENT POINT.
• There are some caveats associated with 6500 series switches.

______________________________________________________________

PfR INTERFACES

• EXTERNAL :- Defined on MC.
• Used for ACTIVE monitoring.
• INTERNAL :- Defines on MC.
• Used for PASSIVE monitoring with NetFlow.
• BOTH INTERFACES EXIST ON BR AND DEFINED ON MC.
• LOCAL :- Used for BR to MC communication.
• Defined on BRs
• FOR A SINGLE MC/BR, A LOOPBACK SHOULD BE USED.

________________________________________________________________

CONFIGURATION STEPS

• CONFIGURE MC
• Create KEY CHAIN
• Define MC
• oer master
• Takes CLI into a SUB-MENU
• Define BRs on MC
• border (IP) key-chain (NAME)
• OWN LOOPBACK IP IS USED IF MC/BR IS ONE AND THE SAME.
• Takes CLI FURTHER into another SUB-MENU
• Define INTERFACES in BR sub-menu
• interface (NAME) internal|external
• External takes CLI into a FURTHER SUB-MENU.
• Define BRs
• oer border
• Define LOCAL interface - MC is POINTING to this IP.
• local
• Define MC on BR
• master key-chain ()

__________________________________________________________________

VERIFICATION

• show oer master
• Issued on MC
• show oer border
• Issued on BR

INE OLS - PFR DEMYSTIFIED

INSTRUCTOR - ANTHONY SEQUEIRA


INTRODUCTION

• Performance Routing
• Formerly known as OER - Optimized Edge Routing.
• Most syntax still remains SAME.
• Differs from TRADITIONAL routing as in it moves AWAY from the paradigm where routing is based on DESTINATION alone. Instead, PERFORMANCE is taken into consideration.
• Given a scenario where there are TWO exit points out of an AS.
1. LOW BW BUT LOW DELAY
2. HIGH BW BUT HIGH JITTER
• PfR will allow transmission of VOICE through ONE and DATA through the SECOND exit.
• Happens dynamically.
• Originally engineered for OUTBOUND traffic manipulation BUT CAN NOW INFLUENCE INBOUND FLOWS.

_____________________________________________________________
CORE COMPONENTS

• MASTER CONTROLLER (MC)
• The BRAINS of the whole operation.
• Collects statistical data and UPDATES policy decisions.
• Eg. Prefix injection.
• DOES NOT HAVE TO BE IN TRAFFIC PATH. 
• BORDER ROUTERS (BR)
• Located at the network EDGE.
• IN THE TRAFFIC PATH.
• Enacts policy dictated by MC and CONTROLS traffic IN and OUT of external links.
• INTERNAL LINKS DO NOT HAVE TO BE TRAFFIC PATH.
• A Cisco router can funciton as a BR and MC SIMULTANEOUSLY. 

_______________________________________________________________
THE PROCESS

• PROFILE PHASE
• Identifies the TRAFFIC CLASSES that need to be controlled.
• TC can be DISCOVERED by PfR or MANUALLY DEFINED.
• MEASURE PHASE
• BRs collect statistics and REPORT them to MC.
• Measurements can be ACTIVE or PASSIVE
• Passive - Interface statistics, NetFlow.
• Active - IP SLA used to GENERATE and MEASURE traffic.
• APPLY POLICY PHASE
• Acceptable thresholds of performance are defined.
• MC uses this info to IDENTIFY classes or links that are OUT OF POLICY (OOP)
• CONTROL PHASE
• IMPORTANT BUT NOT MANDATORY PHASE.
• Here, MC controls ROUTING PROTOCOL decisions.
• INJECT STATIC or BGP routes, CHANGE METRICS etc.
• VERIFY PHASE
• ENSURE the changes have brought the network BACK IN POLICY.

_______________________________________________________________
MC AND BR SETUP

• Basic setup is SIMPLE; most subsequent configuration occurs on MC.
• MASTER CONTROLLER SAMPLE CONFIG
• key chain ()
• key #
• key-sting ()
• !
• oer master
• keepalive ()
• logging
• !
• border (IP) key-chain ()
• interface (NAME) [internal | external]
• KEY CHAIN SETUP IS MANDATORY.
• LOGGING IS OPTIONAL BUT HELPFUL IN SETUP
• INTERFACE NAMES ARE ON THE BR!!!!!!!!!!
• EXTERNAL route OUT.
• INTERNAL connect BR to MC.
• BORDER ROUTER SAMPLE CONFIG
• key chain ()
• key #
• key-sting ()
• !
• oer border
• local (INTERFACE) <---------- LOCAL IP USED
• master (IP) key-chain ()
• VERIFICATION
• show oer master|border

_________________________________________________________
THE PfR PROFILE PHASE

• Dynamic discovery of TC (LEARN) or MANUAL configuration.
• Any TC PROFILED are stored in MONITORED TRAFFIC CLASSES (MTC) table.

• LEARNING PREFIX TRAFFIC CLASSES
• Uses the NetFlow TOP TALKER feature.
• Identifies prefixes with HIGHEST THROUGHPUT OR DELAY.
• Aggregation and limits CONTROL the SIZE of the MTC.
• MINIMAL BASE CONFIG for dynamic learning :-
• oer master
• learn
• throughput
• delay

• LEARNING APPLICATION TRAFFIC CLASSES
• Use the command protocol to identify ONLY those flows associated with an application.

• CONFIGURING A PREFIX TRAFFIC CLASS
• Prefixes are MANUALLY added to the MTC table using an OER-MAP.
• OER map contains ONLY PERMIT entries.
• Use PREFIX-LIST to DENY certain subnets.
• SAMPLE CONFIGURATION
• oer-map (NAME)
• match ip address prefix-list ()
• !
• oer master
• policy-rules
• VERIFICATION
• show oer master prefix learned

_______________________________________________________
THE PfR MEASURE PHASE

• BRs PASSIVELY measure the MTC information OR ACTIVELY PROBE (IP SLA) configured targets.
• ALSO monitor the the configured EXTERNAL links (LOAD/ERRORs)
• Here, PfR classifies TC and LINKS into STATES. POLICY DECISION POINT (PDP)
• default - TC or LINK is NOT under PfR control.
• choose exit - PfR is ATTEMPTING to select an EXIT POINT based on PERFORMANCE and configured POLICY.
• holddown - The MC has REQUESTED a BR to MONITOR the TC.
• in-policy - Traffic is being forwarded through an interface that SATISFIES the default or user-defined policy.
• out-of-policy - NO exits conform the policy. The MC may have to select the BEST available exit.
• PASSIVE measurement is done with NETFLOW.
• ACTIVE measurement is done with IP SLA.

• SAMPLE CONFIGURATION
• oer master
• active-probe echo (IP)
• Supported test are :
• ICMP echo
• UDP echo
• Jitter
• TCP connection.

______________________________________________________________
THE PfR APPLY PHASE

• Policy can be applied that DICTATES ACCEPTABLE values from the MEASURE phase.
• Timers help to ensure that network is NOT UNSTABLE as a result of PfR.
• Policies are applied using the OER-MAP
• Can be set GLOBALLY or for SPECIFIC TC.
• SAMPLE CONFIGURATION
• oer-map (NAME)
• match ip address prefix-list ()
• set delay threshold ()
• !
• oer master
• policy-rulse (OER-MAP-NAME)

___________________________________________________________
THE PfR APPLY PHASE

• OPTIONAL
• Here, PfR actually CHANGES the FLOW of traffic based on MEASUREMENTS and the POLICY.
• The mode route control places PfR in a mode where commands are sent to BRs to CONTROL ROUTING.
• Changes are initiated when :-
• A TC goes OOP.
• An exit link goes OOP.
• The periodic timer EXPIRES and TC are in CHOOSE EXIT.
• Changes are enacted though IGP metric change, BGP attribute manipulation, route injection or PBR introduction.

__________________________________________________________
THE PfR VERIFY PHASE

• This phase ENSURES that TC are brought back IN POLICY.
• NetFlow is relied upon for VERIFY phase.

NMC VOD Series - Lesson MPLS

Part 1 : BASIC CONFIGURATION

• MPLS Layer 3 VPN BASICS
• On Provider Edge router, each VPN (CUSTOMER) has its OWN Virtual Routing and Forwarding table (VRF).
• Each VRF has TWO associated values it, Route Distinguisher and Route Target.
• To setup a VRF :-
• ip vrf
• rd AA:NN
• route-target import AA:NN
• route-target export AA:NN
• To assign an interface to a VRF :-
• ip vrf forwarding
• Routes redistributed INTO MP-BGP from the VRF are marked with EXPORT RT (BGP extended community)
• On the receiving router, routes are IMPORTED into a VRF using the IMPORT RT.
• Routes are TRANSPORTED across the MPLS core between PE routers using MP-BGP updates.
• A 64-bit RD is COMBINED with IPv4 prefixes to create a GLOBALLY UNIQUE VPNv4 route.
• Depending on the protocol being redistributed in MP-BGP, BGP extended communities are utilized to REPORT route attibutes such as :-
• Route source
• Route type
• Route metric
• UNICAST traffic between CUSTOMER sites, ACROSS the core between PEs uses MPLS.
• TWO LABELS are used (STACKED)
• TOP (TRANSPORT) label is SWAPPED/CHANGED HOP-TO-HOP towards the FAR side PE.
• INNER (VPN) label remains UNCHANGED.
• This is the label used by DESTINATION PE to determine the VPN/VRF the packet belongs to.
• MP-BGP is used as the CONTROL protocol to exchange the VPN labels between PE routers.

_______________________________________________________________________________

• BASIC LAYER-3 VPN CONFIGURATION
• ENABLE MPLS IN THE CORE
• Advertise CORE links via an IGP.
• ENABLE LDP on core links.
• ENABLE MP-BGP session between PE routers.
• Peer the PEs in global BGP.
• In the VPNv4 address-family, ACTIVATE the PE neighbors.
• Configure them, in the VPNv4 address-family to exchange BGP extended communities.
• Create the respective VRFs on PE routers.
• DEFINE :-
• VRFs
• RDs
• IMPORT/EXPORT RTs.
• Associate interfaces with VRFs.
• Usually the value of RT and RD is left the SAME for SANITY's sake but it is the RT value that is used to CONTROL the content of VRF table.
• On receiving router, a route's RD is NATURALIZED to match the DESTINATION VRF's RD.
• show ip vrf is used to VERIFY the VRFs.
• ENABLE routing for PE-CE.
• Can be ANY IGP with each having its own demands.
• MANUALLY redistribute IGP into MP-BGP on the PE routers.
• Also redistribute, inside proper VRF, BGP into IGP.
• Redistribution is done under address-family vrf (name) ipv4 in MP-BGP.

_______________________________________________________________________________ PART 2 : TESTING AND VERIFICATION

• Test reachability WITHIN each VPN via PING, TRACEROUTE etc.
• no mpls ip propagate-ttl makes the P core TRANSPARENT by NOT copying the TTL value of the IP packet header to MPLS header.
• THIS VALUE IS COPIED BY DEFAULT.
• Test and verify ALL VRFs on PE routers.
• Use PING, TRACEROUTE and TELENT PER VRF on the PEs.
• Use show ip bgp vpnv4 all
• Shows a SEPERATE BGP table for each RD/VPN/VRF.
• Prefixes are sorted into the CORRECT VPN table by thier RD values.
• show ip bgp vpnv4 (IP)
• Shows individual prefix's information.
• IP next-hop
• Prefix metric
• RT
• RD/VPN label

________________________________________________________________________________

• VPN AND LDP LABEL DISTRIBUTION
• PEs assign VPN labels to PREFIXES to identify LOCAL VPNs.
• Advertised via MP-BGP to FAR-SIDE PE for it to use as INNER LABEL when sending back a packet.
• LDP is used to advertise the TRANSPORT label HOP-by-HOP for PE-P-PE.
• TIP :- TAG/LABEL ADVERTISED BY ONE PE ROUTER IS USED BY ITS NEIGHBOR TO SEND DATA BACK TO ADVERTISING ROUTER.
• TRUE FOR CONNECTED NEIGHBORS IN LDP AS WELL.
• Switching of packets INSIDE the core takes place SOLELY on the base of LABEL imposed on the packet.
• NO IP LOOKUP TAKES PLACE.

_________________________________________________________________________________ PART 3 - PE-CE ROUTER RELATIONSHIP

• Using OSPF for PE-CE protocol.
• On PE, configure ONE GLOBAL process and ONE process for EACH VPN.
• Each OSPF PROCESS-ID must be DIFFERENT.
• Each OSPF process on the PE router MUST HAVE A DIFFERENT ROUTER-ID
• If there is an AREA 0 in the customer site, it MUST connect to the PE router.
• VRF aware OSPF :-
• router ospf (PID) vrf (NAME)

_________________________________________________________________________

• OSPF-BGP INTERACTION
• Manually redistribute between OSPF and BGP at the PE routers.
• NORMALLY, NO ADJACENCY IS FORMED ACROSS THE CORE
• BGP reports the ORIGINAL OSPF metric in MED attribute.
• ORIGINAL AREA and ROUTE-TYPE are reported as an EXTENDED COMMUNITY VALUE.
• A new value called DOMAIN-ID is reported and compared.
• EQUAL to PROCESS-ID by default.
• Can be changed in the OSPF process - domain-id #
• ALL routes are redistributed as LSA-5 (external) if their DOMAIN-ID differs from the local one.
• If SAME, routes are redistributed as LSA-3 (InterArea)
• Core is called the SUPER BACKBONE and ADD another layer of hierarchy.
• Extended community OSPF RT = X:Y:Z reports :
• X = Original AREA
• Y = Original LSA #
• Z = 1 or 2 if LSA # is 5 or 7.
• Reports metric type 1 or 2 for external LSA 5 or 7.

____________________________________________________________________________

• OSPF LOOP AVOIDANCE AND SHAM-LINKS
• Connecting customer sites to MULTIPLE PE routers can result in ROUTING LOOPS.
• OSPF uses the concept of DOWN BIT in its redistributed LSA's and SHAM-LINKS to overcome these problems.
• HOW THE DOWN-BIT AND ROUTE TAG STOP LOOPS
• The DOWN-BIT keeps LSA-3/IA routes from REMOTE sites from being redistributed BACK into MP-BGP.
• The PE router that receives the OSPF LSA-3 in MP-BGP updates sets the DOWNWARD bit on the LSA.
• If another PE router receives this LSA from a VRF ENABLED INTERFACE, it will CLEAR the ROUTING-BIT on the LSA, THEREBY STOPPING THE LSA FROM BEING REDISTRIBUTED BACK INTO MP-BGP.
• Similarly, a ROUTE-TAG keeps LSA-5/EX routes from being redistributed BACK INTO MP-BGP.
• LSA-5 DO NOT support the concept of DOWNWARD-BIT.
• Instead, a route-tag defined by RFC 1403 is used.
• LAST 16 bits of the TAG define the BGP-AS the LSA was learnt from.
• PE routers will IGNORE the LSA if the LOCAL AS matches ROUTE-TAG AS.
• Downward-bit can cause an unnecessary problem if the CE router is using VRFs on its PE-CE interface.
• Namely, the LSA with the down bit will have its routing bit cleared and will not be used to install routes into the routing table.
• To overcome this issue, the special OSPF command capability vrf-lite is used.
• This makes the CE router IGNORE the down bit and install the LSA into the RIB.
• Using DIFFERENT DOMAIN-IDs to produce LSA-5 at the REMOTE END of MPLS core is the alternative and especially useful on catalyst switches that DO NOT support the above command.
• The LSA-5, as noted above, do not have the concept of the downward bit and hence will be installed as normal.

__________________________________________________________________

• OSPF SHAM-LINK
• Sham-link creates a VIRTUAL INTRA-AREA path/link through the MPLS CORE BETWEEN THE PE ROUTERS.
• This is needed to OVERCOME the OSPF preference for INTRA-AREA routes over ANY other routes.
• Useful when the customer sites have a BACKDOOR link configured that is an INTRA-AREA link.
• Once configured, the PEs will form and ADJACENCY across the MPLS core and exchange ROUTER-LSA (1).
• COST of this link can now be manipulated to give the sham-link PREFERENCE over the BACKDOOR.
• area (#) sham-link (local-IP) (remote-IP)
• show ip ospf sham-link
• END POINTS MUST BE CUSTOMER VRF HOST ROUTES.
• Usually REDISTRIBUTED into MP-BGP and NOT advertised in OSPF itself to overcome RECURSIVE routing problems.
• SHAM-LINK WILL BE CONFIGURED UNDER THE CUSTOMER VRF OSPF PROCESS.

_____________________________________________________________________

• SUPPORTING EIGRP AS PE-CE PROTOCOL
• EIGRP uses the concept of address-family just like MP-BGP.
• autonomous-system (#) inside the address-family allots the AS to the VRF EIGRP instance.
• If CE sites used DIFFERENT EIGRP AS numbers, the MP-BGP learnt routes are considered external.
• If SAME AS is used, EIGRP behaves as ONE large AS across MPLS core.
• ONE IMPORTANT DIFFERENCE IS THAT QUERIES ARE NOT SENT ACROSS MPLS CORE.
• BGP transports internal metrics and route attributes using EXTENDED communities.
• 0x8800 : 32768 (INTERNAL), 0 (EXTERNAL)
• 0x8801 : AS# / SCALED DELAY ( DLY x 256/10)
• 0x8802 : RELIABILITY, HOP-COUNT, SCALED BW
• 0x8803 : LOAD, MTU
• 0x8804 : REMOTE AS (0 FOR EXTERNAL) / ORIGINATING R-ID IN HEX
• 0x8805 : REMOTE PROTOCOL, R-ID, METRIC (USED FOR REDISTRIBUTED ROUTES)

_______________________________________________________________________

• BGP COST COMMUNITY
• Allows user to CONTROL the use of BACKDOOR paths.
• Contains THREE FIELDS.
1. POINT OF INSERTION (POI) : PRE-BESTPATH permits COMPARISON BEFORE any other route attribute INCLUDING AD.
2. COST COMMUNITY ID : 128 for EIGRP internal routes, 129 for EIGRP extrenal routes. LOWER PREFERRED.
3. COST : EIGRP composite metric.
• Configuration
• Automatic but ROUTE-MAPS can be used to set values using extcommunity keyword and applied to neighbor statement.
• bgp bestpath cost-community ignore can be use to ignore this process.

________________________________________________________________

• BGP SITE-OF-ORIGIN COMMUNITY
• Prevents routing loops when sites are MULTIHOMED.
• EACH route is tagged with a SITE IDENTIFIER.
• Set INSIDE a SPECIAL ROUTE-MAP.
• set extcommunity soo AA:NN
• Applied to customer VRF via a SITE-MAP.
• ip vrf sitemap
• This makes sure that the router will APPLY a TAG on EACH EIGRP route learnt VIA THIS INTERFACE.
• Conversely, EIGRP will FILTER any updates containing this tag from ENTERING the interface.

________________________________________________________________

• USING BGP AS PE-CE PROTOCOL
• CEs on remote ends can be EITHER in SAME or DIFFERENT ASs.
• CE's form eBGP peerings with PEs.

_____________________________________________________________

• CUSTOMER USING A DIFFERENT BGP AS AT EACH SITE
• On PE routers, the BGP peering is configured under address-family ipv4 vrf () for the respective CEs.
• The CE neighbor is ACTIVATED to enable the exchange of routing information for the VRF.
• The CE routers in the VPN are configured for NORMAL eBGP peering with PE.
• VPNv4 prepends the RD to EACH advertised prefix, IDENTIFYING it with CORRECT VRF on the far side PE.
• The CE routers receive ONLY the updates from their VPN.

_____________________________________________________________

• CUSTOMER USING THE SAME BGP AS AT EACH SITE
• The BGP loop-prevention (AS-PATH) mechanism prevents ONE site from successfully learning prefixes from ANOTHER.
• SOLUTION 1 :- The as-override keyword can be used to MODIFY BGP update procedure.
• EACH leading occurrence of customer AS is replaced by provider's AS.
• USED on PE routers.
• CAN OVERCOME AS-PATH PREPENDING.

• SOLUTION 2 : - The allowas-in can alternatively used on CE routers to ACCEPT routes with OWN AS in AS-PATH.

___________________________________________________

• MULTI-VRF CE (VRF-LITE)
• The VRFs are EXTENDED from PE to CE routers in these types of scenario.
• A TRUNK (using sub-interfaces in separate VRFs) between PE and CE keeps costs down and eases configuration.
• EACH sub-interface is associated with VRF on BOTH sides of the trunk.
• The ROUTED CE interfaces are ALSO configured for the VRFs.
• Since CE routers are VRF-aware, capability vrf-lite will need to be used in OSPF for IGNORING LSA-3 with downward bits.

INE OLS - NETFLOW w/ KEITH BARKER

• WHAT DOES NETFLOW DO?
  • NetFlow is an ACCOUNTING feature ON TOP of an existing switching path. Eg. CEF.
  • NetFlow provides STATISTICS on packets flowing through the router.
    • INGRESS : IP, IP to MPLS, FR/ATM and traffic destined TO THE ROUTER ITSELF.
    • EGRESS : Traffic generated BY THE ROUTER IS NOT CAPTURED.

______________________________________________________________

• USING NETFLOW DATA
  • NetFlow data can be used for :-
    • Network application and user MONITORING.
    • Network PLANNING.
    • DOS and security ANALYSIS.
    • ACCOUNTING and BILLING.
    • TRAFFIC ENGINEERING.

____________________________________________________________

• WHAT IS A FLOW?
  • Initially, a single flow is the combination of SEVEN key fields.
    • SOURCE IP.
    • DESTINATION IP.
    • SOURCE PORT.
    • DESTINATION PORT.
    • LAYER-3 PROTOCOL TYPE.
    • TOS BIT.
    • LOGICAL INTERFACE (ifIndex).
  • Flows are subject to TIMEOUTS. 15 seconds by default.
  • Flows are STORED in NETFLOW CACHE.

______________________________________________________________

• LIFE CYCLE
  • Router notices network traffic and CREATES flows in NetFlow cache LOCALLY.
  • ACTIVE FLOWS EXPIRE. Nothing lasts forever.
  • Router EXPORTS flow records to COLLECTORS.
    • Non aggregated flows only in Version 5 or 9.
    • Aggregated flows in Version 8 and 9.
    • Transparent protocol UDP or SCTP is used.
      • SCTP – Stream Control Transparent Protocol.
    • An OPTIONAL aggregation cache may be created and exported as well.
  • FLOW HAS TO EXPIRE BEFORE IT IS EXPORTED.
  • Flows can be AGGREGATED OR SUMMARIZED on SOME of the key-fields.

________________________________________________________________

• NETFLOW PRE-PROCESSING
  • Packet sampling.
    • Sets up STATISTICAL SAMPLING of network traffic for TE or capacity planning.
  • Filtering.
    • Sets up a SPECIFIC SUBSET of network traffic for CLASS-BASED traffic analysis.

__________________________________________________________________

• EXPIRATION OF A FLOW
  
  
  • Inactivity timer – 15 seconds by default.
  • Active timer expiration – 30 mins by default.
    
    
    • Simply means that the information is sent for a flow active for LONGER than 30 mins.
    • Router NO LONGER waits for expiration.
    • SESSION IS NOT BROKEN. Just the information about it is sent.
  • NetFlow cache is FULL (FIFO).
  • TCP RST or FIN is observed.

_________________________________________________________________

• NETFLOW POST PROCESSING
  
  
  • Aggregation schemes.
    
    
    • Quite simply summarization.
    • Sets up EXTRA aggregation caches with different combinations of fields that determine WHICH TRADITIONAL FLOWS are GROUPED TOGATHER.
      
      
      • Several NON-TOS and TOS based schemes.
      • Uses ADMIN-DEFINED NON-STANDARD KEY-FIELDS.
  • Export to MULTIPLE destinations.
    
    
    • Sets up IDENTICAL streams of NetFlow data to be sent to MULTIPLE hosts.

__________________________________________________________________________

• EXPORTING NETFLOW
  
  
  • Version 5 INCLUDES BGP AS information.
  • Version 7 ONLY supported on CATALYST switches.
  • Version 9 defined in RFC 3954.
    
    
    • FLEXIBLE AND EXTENSIBLE using templates.
  • Version 10 – IETF IP Flow Information eXport – IPFIX.

___________________________________________________________________________

• TERMINOLOGY
  
  
  • FLOW
    
    
    • The ACTUAL traffic that occurred.
  • FLOW-RECORD
    
    
    • Information about the traffic.
  • EXPORT-PACKET
    
    
    • Transported to the collector.
  • PACKET HEADER
    
    
    • Has VERSION, SEQ #, # OF RECORDS etc.
  • TEMPLATE RECORD (SCHEMA)
    
    
    • DEFINES fields and structure in flow-record.
  • OPTIONS RECORD
    
    
    • Data ABOUT the CONFIGURATION OF NETFLOW.
    • Examples include – SCOPE, SAMPLING LEVELS etc.

______________________________________________________________________________

• STREAM CONTROL TRANSPORT PROTOCOL
  
  
  • RFC 2960 and extension RFC 3758.
  • Reliable transport protocol for EXPORT.
  • Stream 0 is the CONTROL channel.
  • Additional streams are for carrying data.

____________________________________________________________________________

• COMMANDS.
  
  
  • Ip flow-capture
  • ip flow-cache
  • ip flow-export
  • (config-if)# ip flow ingress|egress
  • show ip flow export|interface
  • show ip cache flow <------------------ IMPORTANT
  • show ip cache flow verbose flow
  • sho ip flow top-talkers
  • flow-sampler-map
    
    
    • mode
  • (config-if)# flow-sampler egress|ingress

_______________________________________________________________________________

• FLEXIBLE NETFLOW
  
  
  • Basic ingredients are :
    
    
    • RECORDS.
      
      
      • Pre-defined.
      • User-defined.
    • Flow exporters.
      
      
      • Used by FLOW MONITORS for exporting NetFlow data.
    • Flow MONITORS.
      
      
      • Linked to an exporter and record.
      • Applied to interfaces.
      • Creates its OWN cache.
        
        
        • Normal.
        • Immediate
        • Permanent.

INE OLS - ADVANCED ZONE BASED FIREWALL

INSTRUCTOR - MARVIN GREENLEE


ZBF vs. IOS FIREWALL

• IOS FW is INTERFACE BASED
• ZFW is based on LOGICAL GROUPINGS of interfaces.
• Adds a degree of VIRTUALIZATION.
• Zones can have ONE or MANY interfaces.

___________________________________________________
ZONES

• Logical groupings of ONE or MORE interfaces.
• Have a set of DEFAULT behaviors, SOME of which can be changed via policy.

_______________________________________________________
SELF ZONE

• SPECIAL zone used for traffic TERMINATING on the router itself.
• Eg. Telnet, TFTP, HTTP traffic etc.
• Can be though of LOOSELY as CONTROL PLANE.
• Traffic TO an interface on the router.

_______________________________________________________
ZONE PAIR

• LOGICAL pairings of TWO zones for a UNIDIRECTIONAL policy.

_________________________________________________________
ZONE CONFIGURATION

• Defined GLOBALLY.
• Interfaces ASSIGNED to zones.
• REFERENCED IN ZONE PAIRS.

_________________________________________________________
GENERAL RULES

• Zones need to be configured BEFORE interfaces are assigned.
• An interface can ONLY be assigned to a SINGLE ZONE.
• Transparent ZFW works differently.
• Traffic BETWEEN interfaces in the SAME zone is NOT FILTERED.
• Traffic TO or FROM the SELF zone will PASS by default.
• Traffic WILL NOT pass from a ZONE MEMBER to a NON-ZONE MEMBER.
• Traffic WILL pass from a NON-ZONE to a NON-ZONE member.

________________________________________________________
HIERARCHY 

• ZFW uses MQC structure.
• All structures - Class-maps, Policy-maps and Service policy are of TYPE INSPECT.

_________________________________________________________
CLASS MAP

• TYPE INSPECT.
• BEWARE of match-any vs. match-all.
• DEFAULT IS MATCH-ALL.
• MATCH PROTOCOL options based on IOS FW protocol definitions.
• NOT NBAR!

___________________________________________________________
POLICY MAP

• Match CLASSES and define ACTIONS.
• Options are DROP, PASS and INSPECT.
• Drop - Straightforward drop.
• Pass - Traffic is allowed to PASS.
• Inspect - Traffic is allowed to pass AND ADDED to STATE TABLE to ALLOW RETURN traffic.
• Additional options such as LOGGING, CONNECTION LIMITS, POLICE etc. are available.

__________________________________________________________
SERVICE POLICY

• BINDING the policy to ZONE-PAIRS.

__________________________________________________________
COMMANDS
    
      1. DEFINE ZONES

• (config)# zone security NAME

      2. DEFINE ZONE-PAIRS

• (config)# zone-pair security NAME source ZONE-1 destination ZONE-2

      3. DEFINE CLASS-MAPS AND POLICY-MAPS

• (config)# class-map type inspect NAME
• match protocol|access-group etc.
• (config)# policy-map type inspect NAME
• class NAME
• drop|pass|inspect|police|urlfilter
• service-policy type inspect

      4. APPLY POLICY-MAP TO ZONE-PAIRS

• (config)# zone-pair security NAME
• service-policy type inspect NAME

      5. ASSIGN INTERFACES TO ZONES

• (config)# interface NAME
• zone-member security NAME

      6. VERIFICATION

• show policy-map type inspect zone-pair NAME

________________________________________________________
COMMON PROBLEMS

• PASS vs. INSPECT - Return traffic depends on this.
• "Self" zone is NOT BLOCKED by default.
• CLASS-DEFAULT with a DEFAULT ACTION OF DROP.
• Drop log can be used to LOG to CONSOLE.
• Ip inspect log drop-pkt logs ALL drops.
• For some protocols, actions such as INSPECT are LIMITED under SELF zone.
• Policies for SELF zone are IMPORTANT FOR ROUTING PROTOCOLS.

_______________________________________________________
PAM

• Port Application Mapping.
• Allows MAPPING for CUSTOM ports and protocols.
• Available in BOTH IOS and ZONE FW.
• ip port-map NAME port PROTOCOL NUMBER
• This MAPPED protocol can be referenced in match protocol NAME.
• This creates a NEW mapping.
• An EXISTING mapping can also be ADJUSTED.
• Eg. ip port-map telnet port tcp 1024
• Match protocol telnet will now match TCP port 1024 in ADDITION to port 23.

________________________________________________________
PARAMETER MAP

• ADDITIONAL OPTIONS for inspect -
• Audit trails, maximum connections, incomplete connections etc.
• DEFAULTS VARY WITH IOS VERSION.
• Values can be TUNED as needed for specific environment.
• The values of PARAMETER MAP in ZFW are PER CLASS.
• parameter-map type inspect NAME
• Choose parameters in this sub-menu.
• The map should then be applied to a POLICY via inspect keyword.
• Inspect NAME

________________________________________________________
TRANSPARENT ZONE FIREWALL

• Allows configuration of a policy BETWEEN TWO LOGICAL VLANS.
• Utilizes BRIDGE-GROUPS and BRIDGING for the VLANs.
• BRIDGED interfaces are simply assigned to ZONES..
• Policy can still be configured for traffic leaving via ANOTHER interface.
• The idea is to ENFORCE policy BETWEEN TWO INTERFACES IN SAME ZONE.
• The BVI can be used to this effect.
• The fact that should be remembered that as long as packets are BRIDGED, the policy in effect is the one on BRIDGED interfaces BUT when packets are ROUTED out to OTHER domains, the POLICY on BVI is in effect.
• It is POSSIBLE (NOT RECOMMENDED) to configure Layer-2 and Layer-3 interfaces in the SAME ZONE.
• Desirable in MOST cases to keep these domains separate.
• Any BVIs on the routers belong to SELF zone.
• An ACL may still be applied to BVI if no security zone is assigned.
• If the WHOLE L-2 domain BEHIND the BVI needs to be treated as a SINGLE Layer-3 security zone, a zone may be applied to BVI, BUT NOT BRIDGED interfaces.
• MC/BC are NOT inspected.
• Moreover in transparent mode, BOTH are permitted across FW configured with ZONES.

MPLS Day 2

Workbook One Observation and Analyses.

• OSPF Sham-links
• When OSPF is propagated via MP-BGP over MPLS core, the prefixes received from the other end are interpreted as EITHER LSA Type-3 or Type-5 or INTER-AREA routes.
• Causes problems when a backdoor, BACKUP link is used between the CE routers, independently, outside the MPLS domain.
• If the backup link is in the SAME area as the CE routers, it will be an INTRA-AREA route.
• This means, because of OSPF's design, it WILL ALWAYS be PREFERRED to the INTER-AREA routes learnt over the MPLS cloud.
• Issue can ONLY be resolved by configuring MPLS core to be in the SAME area as the CE routers.
• Solution is to use a SHAM-LINK.
• Special tunnel similar to a virtual link connecting TWO PE routers, configured in the SAME area as CEs.
• Link is used to ESTABLISH an ACTUAL adjacency BETWEEN PEs and exchange LSAs.
• Once these LSAs are loaded into the OSPF database, the SHAM-LINK is used for INTRA-AREA path computation.
• HOWEVER, when the routes are being installed in the VRF, the FORWARDING information is based on looking up MP-BGP learned routes' EXACT prefix match.
• Corresponding VPN and Transport labels are then used for ACTUAL packet forwarding over MPLS cloud.
• REMEMBER – INFORMATION LEARNED ACROSS SHAM-LINK IS USED ONLY FOR SPF CALCUATIONS AND BEST-PATH SELECTION.
• ACTUAL FORWARDING IS BEING DONE BASED ON INFO LEARNT OVER MPLS VIA MP-BGP.
• Sham-links are sourced off actual interfaces configured in respective VRFs. Loopbacks are MOST commonly used.
• IPs for these endpoinds should be advertised by some means OTHER THAN OSPF.
• area # sham-link cost (cost)
• SHAM-LINK ENDPOINTS SHOULD NOT BE ADVERTISED IN OSPF.
• IN ADDITION, THEY HAVE TO BE FULLY MASKED – /32.

—————————————————————————————————————————————————

• PE-CE Routing with EIGRP
• MP-BGP stores EIGRP information in special extended communities with are preserved over MPLS core.
• Original metric values
• Route-type
• Source AS
• Remote router-id
• Metric is not carried simply in MED as there exists a remote possibility that the two sites DO NOT agree on K-values.
• Any routes with AS different than LOCAL AS are considered EX/external routes.
• Another special attribute is the “cost attribute”
• Main idea is to CHANGE BGP bestpath selection.
• Problem is SAME path may enter PE BGP table in TWO ways -
• via Redistribution – Learnt from CE
• via BGP update – Learnt from REMOTE PE
• Per BGP path selection, locally redistributed routes have a weight of 32768 – PREEMPTS bestpath selection is IOS and ALWAYS wins.
• THUS, there lies the potential that BGP will ALWAYS use the locally redistributed route, even though the METRIC of the path learnt across MP-BGP is better.
• To resolve this issue, EIGRP prefixes redistributed into MP-BGP have teh COST ATTRIBUTE set to the composite metric.
• BGP process HONORS the cost attribute value BEFORE ANY OTHER bestpath selection option IF cost indeed is present in a prefix.
• Prefix with LOWEST cost immediately wins the bestpath selection AND WILL BE redistributed INTO the local EIGRP prcess.
• Process is AUTOMATIC.
• This is NOT a potential problem is OSPF as prefixes learnt via MP-BGP are treated as INTER-AREA and ALWAYS less preferred when compared to same prefixes learnt via CE.
• When configuring EIGRP for MPLS, same process is SHARED amongst MULTIPLE VRFs.
• An address-family MUST be configured per VRF.
• For every address-family, an AS number MUST BE CONFIGURED –autonomous-system
• ABOVE STEP IS MANDATORY to enable EIGRP for that VRF.

—————————————————————————————————————————————————

• EIGRP Site-of-Origin
• Multi-homed scenarios where BGP and EIGRP perform MUTUAL redistribution at PE routers, there is potential for TRANSIENT routing loops.
• When a prefix is WIDRAWN in MP-BGP at ONE PE router AND IS NOT TIMELY propagated to EIGRP, then EIGRP gets a chance to feed the INVALID ROUTE into MP-BGP at a DIFFERENT PE router.
• Core of this problem is the mutual redistribution that allows information from BGP at ONE site to RE-ENTER BGP at another site.
• This can usually be solved by tagging.
• IOS implements a special feature called SoO that uses an extended community appended to BGP AND EIGRP routing updates. (TLV structure of EIGRP makes this easy to implement).
• Feature is configured at INTERFACE level
• ip vrf sitemap
• set extcommunity soo ASN:NN
• All BGP prefixes redistributed into EIGRP and sent OVER the interface will have this community appended BUT ONLY IF THE COMMUNITY IS NOT ALREADY PRESENT.
• If the update is to be sent ALREADY has the SAME SoO, it is discarded as being redistributed back to the same site.
• NEXT, the feature applies the SAME SoO to all EIGRP routes received on this interface and REDISTRIBUTED INTO BGP.
• Two COMMON ways to apply
• SoO is applied on PE interfaces facing CE ONLY.
• Every PE use SAME value
• Prevents PEs from learning MP-BGP originated routes from CE.
• SIDE-EFFECT – MPLS core CANNOT be used as a “backup” path BETWEEN segments of MULTI-HOMED sites.
• Because MP-BGP updates for in-site EIGRP prefixes carry the SAME SoO applied to PE-CE interfaces and CANNOT be redistributed back to the site.
• DIFFERENT values of SoO are used at EACH PE-CE interface.
• To prevent PE to PE feedback, additional SoO interface is configured on the BACKUP interface between CE-CE.

—————————————————————————————————————————————————

• PE-CE Routing with BGP
• Simple configuration with eBGP peering between the PE-CE.
• Common problem that arises is that MULTIPLE sites for the same organization MAY use the SAME AS number for BGP.
• Due to eBGP loop prevention, this FILTERS prefixes learnt from one site from entering the other side with SAME AS.
• TWO solutions :

1. allowas- in option inbound at CE for the PE peer.
2. as-override option on PE routers for CE peering sessions.

• Compares remote-as number with AS# stored AT THE END OF AS_PATH.
• If a MATCH, the AS_PATH AS# is REPLACED with LOCAL-AS #
• POSITIVE SIDE-EFFECT – Length of AS_PATH REMAINS SAME.

____________________________________________________________________________________________

• BGP SoO Attribute
• as-override may result in LOOPS for multi-homed sites with BACKUP links.
• To prevent loops, BGP implements SoO
• Value configured PER-NEIGHBOR peering session
• TWO methods
• neighbor soo
• Available in 12.4(11) T and above
• set extcommunity soo in a route-map AND APPLYING IT INBOUND
• WILL NOT WORK ON OUTBOUND MAPS
• Works similarly to EIGRP SoO
• If an incoming/outgoing update has SoO MATCHING locally configured one, UPDATE IS DROPPED.
• ELSE, update is TAGGED with LOCAL SoO.
• To use MPLS as BACKUP
• Use different SoO at PEs
• Apply SoO at CEs over the BACKDOOR.