MTCINE Bootcamp + IPv6 Workshop MTCINE + IPV6 MIKROTIK CERTIFIED INTER-NETWORKING ENGINEER BOOTCAMP + IPV6 WORKSHOP CAGAYAN DE ORO, PHILIPPINES Lay Minh (Makito) Phyo Phyo Hein CCIE # 47682 CCIE R&S written MikroTik Certified Trainer MikroTik Certified Trainer MikroTik Consultant MikroTik Consultant November 03 – 08, 2017 INSTRUCTOR Lay Minh (Makito) MikroTik Certified Trainer & Consultant Chief Technology Officer @ i-BEAM Experiences: 12 years in ISP industry since 2005 Billing solutions for service providers ISP core network design and operations CCIE # 47682 Certifications: Areas of interest: BGP, MPLS, IPv6 1 MTCINE Bootcamp + IPv6 Workshop INSTRUCTOR Phyo Phyo Hein B. C. Tech (hons) MikroTik Certified Trainer & Consultant Director of Information Beam Co., Ltd. Experiences: Cisco instructor since 2005 at i-BEAM Co., Ltd SingTel Mobile Support Network Engineer at NCS Co., Ltd Nera Telecommunications (Singapore) System Integration Manager at Yatanarpon Teleport Enterprise/ISP Manager at Kinetic Myanmar Technology Certifications: Cisco CCNA R&S, CCNP R&S, CCIP, CCIE R&S Written Juniper JNCIA-Junos, JNCDA INTRODUCE YOURSELF Please introduce yourself to the class. Your name Your company Your previous knowledge about RouterOS Your previous knowledge about networking What do you expect from this course? 2 MTCINE Bootcamp + IPv6 Workshop COURSE OBJECTIVES Understand how BGP and the internet work. Understand building blocks of next generation service provider network. Learn about service provider network design and implementation. Learn about MPLS and its enabled services. Discussion on RouterOS IPv6 implementation. For sure, be certified as MTCINE! MIKROTIK CERTIFICATIONS Certification levels 3 MTCINE Bootcamp + IPv6 Workshop MIKROTIK CERTIFICATIONS (CONT.) MTCNA MTCRE Fundamental and overall knowledge about RouterOS First level of MikroTik certification Load Balancing & Load Sharing Site-to-site VPN, VLAN Dynamic routing protocol OSPF Requires MTCNA MTCINE ISP routing protocol BGP MPLS enabled applications L3VPN, L2VPN, Traffic Engineering Requires MTCRE MIKROTIK CERTIFICATIONS (CONT.) MTCWE Wireless concepts Wi-Fi technologies IEEE 802.11a/b/g/n Proprietary protocols NStreme, NV2, NStreme Dual Requires MTCNA MTCTCE RouterOS packet flow Advanced Firewall Bandwidth management, Quality of Service (QoS) DNS, DHCP, Web Proxy…etc. Requires MTCNA 4 MTCINE Bootcamp + IPv6 Workshop MIKROTIK CERTIFICATIONS (CONT.) MTCUME Hotspot PPP BCP IPSec VPN MikroTik User Manager Requires MTCNA MTCIPv6E Introduction to IPv6 Transition mechanism IPv6 interoperability Requires MTCNA MTCINE EXAM Prerequisite: MTCRE Official certification exam will be conducted on the last day of our training. Rules of exam are the same as MTCNA and MTCRE. 25 single or multiple choice questions You have one hour to complete it Exam will end automatically once your time is running out Passing score is 60%, score between 50%-59% will get opportunity to take the exam again Certificate will be expired after 3 years. Same certification exam has to be taken when certificate is expired. 5 MTCINE Bootcamp + IPv6 Workshop CLASS SCHEDULE Class Time 6 days full time bootcamp November 03 – 08, 2017 Morning 09:00 to 12:30 Afternoon 14:00 to 17:00 Lunch break 12:30 to 14:00 Section break time 10 – 15 minutes Q&A after each break CLASS SCHEDULE (CONT.) Day 1 Border Gateway Protocol (BGP) Day 2 Service Provider BGP Design Multiprotocol Label Switching (MPLS) Day 4 Border Gateway Protocol (BGP) (Cont.) Day 3 Day 5 MPLS Layer 3 VPN MPLS Layer 2 VPN Traffic Engineering (TE) Certification Exam Day 6 IPv6 workshop 6 MTCINE Bootcamp + IPv6 Workshop CLASS FORMAT This is an advanced official certification class. Class topics are following to MTCINE training outline: http://www.mikrotik.com/pdf/MTCINE_Outline.pdf Each topic includes lecture and hand-on labs. Live demo by instructor Participants might need teamwork to complete some labs Differs from other classes, all labs in this class are based on Command Line Interface (CLI) Some industry standards and design suggestions will be discussed along the class. The class will be running as workshop-style. Topics beyond our scope are open to discuss at Q&A time. CLASS PREREQUISITE Participants are assumed to know about followings already: RouterOS Command Line Interface (CLI) Bridging Routing concepts Categories of dynamic routing protocols Distance Vector Link State Open Shortest Path First (OSPF) Above topics are covered by MTCNA and MTCRE certification. 7 MTCINE Bootcamp + IPv6 Workshop BORDER GATEWAY PROTOCOL (BGP) Autonomous System iBGP & eBGP BGP Best Path Selection BGP Traffic Engineering Route Filtering & Aggregation AUTONOMOUS SYSTEM (AS) Set of routers under a single administrative control. Routing exchange: Routers within AS use common IGP Routers between ASes use EGP Identified by a unique 32-bit integer, known as Autonomous System Number (ASN). Typically one ISP is one AS. Some ISPs might run multiple ASes for specific purpose For instance, an AS for internet gateway, another AS for local peering or connecting to downstream customers 8 MTCINE Bootcamp + IPv6 Workshop AUTONOMOUS SYSTEM NUMBER (ASN) Two ranges Usage: 0-65535 (original 16-bit range) 65536-4294967295 (32-bit range – RFC4893) 0 and 65535 (reserved) 1-64495 (public Internet) 64496-64511 (documentation – RFC5398) 64512-65534 (private use only) 23456 (represent 32-bit range in 16-bit world) 65536-65551 (documentation – RFC5398) 65552-4294967295 (public Internet) 32-bit range representation specified in RFC5396. Defines “asplain” (traditional format) as standard notation. BORDER GATEWAY PROTOCOL (BGP) A Routing Protocol used to exchange routing information between different ASes. Exterior Gateway Protocol Described in RFC4271. RFC4276 gives an implementation report on BGP RFC4277 describes operational experiences using BGP Network topology is not exchanged, only reachability information. The only routing protocol that can handle Internet's size networks. Classified as a path vector protocol (RFC1322). 9 MTCINE Bootcamp + IPv6 Workshop PATH VECTOR IMPLEMENTATION Treats whole AS as a single point in the path. Prefix is advertised with the list of ASes along the path called AS Path. Prefix means a network or a route in CIDR notation Hides network topology within an AS. Does not guarantee loop-free routing within an AS. IGP (OSPF, IS-IS) will take care of this PATH VECTOR IMPLEMENTATION (CONT.) Prefix 10.1.0.0/24 originated from AS100. 10.1.0.0/24 Add AS100 to the path AS Path: 100 AS100 AS200 Reject, AS100 already in the path Add AS200 to the path AS Path: 200,100 Add AS300 to the path AS Path: 300,200,100 AS300 AS300 receives 10.1.0.0/24 from AS200, AS Path: 200,100. 10 MTCINE Bootcamp + IPv6 Workshop BGP CAPABILITIES BGP speaker advertises supported capability codes. If received capability is not supported, remote peer sends back notification. BGP speaker attempts to peer without unsupported capability. Some of RouterOS advertised capabilities: Route refresh Multi-protocol extension 4-byte AS support BGP TRANSPORT Operates by exchanging Network Layer Reachability Information (NLRI). NLRI includes a set of BGP attributes and one or more prefixes with which those attributes are associated. Uses TCP port 179 as the transport protocol. Initial full routing table exchange between peers. Incremental updates after initial exchange. 11 MTCINE Bootcamp + IPv6 Workshop PACKET FORMAT Uses TLVs (Type-Length-Value): Marker (128-bit) Length (16-bit) Type (8-bit) Value For authentication Message body High extensibility to support new features, i.e. MP-BGP. BGP MESSAGE TYPES Four message types: Open First message sent after TCP connection establishment, contains capability list Confirmed by keepalive Keepalive Does not contain data, sent to keep hold timer from expiring Default keepalive timer is 30 seconds, and hold timer is 180 seconds. Timers are negotiable, peers use the smaller timer Update Actual route updates Contains NLRI and path attributes Notification Sent when error condition occurs, contains error code and sub-code 12 MTCINE Bootcamp + IPv6 Workshop BGP SESSION & UPDATES Open with ASN4 capability AS100 Notification unsupported cap. AS200 Passive BGP peer Open without capability Keepalive AS200 AS100 Route Refresh message Update ENABLE BGP If Router ID is not specified, it is automatically set to lowest IP address on the router. /routing bgp instance set default as=300 router-id=10.10.10.4 /routing bgp peer add instance=default remote-address=10.10.10.1 remote-as=3000 Verify BGP connectivity. Any state other than established indicates that routers can not become neighbors (use “print status” for more details). [admin@R1] /routing bgp peer> print Flags: X - disabled, E - established # INSTANCE REMOTE-ADDRESS 0 E default 10.10.10.1 REMOTE-AS 3000 13 MTCINE Bootcamp + IPv6 Workshop NETWORKS Indicates what networks BGP should originate from the router (max 200). By default network is advertised only if corresponding route is present in routing table. Synchronization can be turned off if: Your AS does not provide transit service All the transit routers run BGP Disabling sync allows BGP to converge faster. Sync can be dangerous if routes are flapping a lot. Configurable from /routing bgp network. IBGP & EBGP There are two types of BGP peer: iBGP – peering between routers inside an AS. eBGP – peering between routers from different ASes. AS200 R2 eBGP AS100 AS300 R3 R1 R4 R5 R6 iBGP eBGP AS400 14 MTCINE Bootcamp + IPv6 Workshop EXTERNAL BGP PEERING (EBGP) Almost always formed between directly connected peers (AS edge/border routers). Multi-hop configuration is required if peers are not directly connected. Loopback peering Load sharing across multiple links Prepend own ASN to advertised prefix's AS Path. By default Nexthop is changed to self. Outgoing interface IP for directly connected peer Update Source IP for multi-hop peer Should never run an IGP between eBGP peers. LAB: EBGP PEERING AS200 AS100 R1 172.16.1.1/24 eth1 172.16.1.2/24 eth1 R2 10.88.0.0/24 Configure your routers according to the topology. Do eBGP peering on connected interface. [admin@R1] [admin@R1] [admin@R2] [admin@R2] /routing /routing /routing /routing bgp bgp bgp bgp instance> peer> add instance> peer> add set default as=100 remote-address=172.16.1.2 remote-as=200 set default as=200 remote-address=172.16.1.1 remote-as=100 Advertise prefix 10.88.0.0/24 on R2. [admin@R2] /routing bgp network> add network=10.88.0.0/24 15 MTCINE Bootcamp + IPv6 Workshop INTERNAL BGP PEERING (IBGP) BGP peer within the same AS. Not required to be directly connected. IGP takes care of inter-BGP speaker connectivity Attributes learned from iBGP are not changed to impact the path selection to reach outside network. AS Path is not manipulated. By default Nexthop is unchanged. iBGP speakers must be fully meshed: They originate connected networks They pass on prefixes learned from outside the ASN They do not pass on prefixes learned from other iBGP speakers LOOPBACK INTERFACE Physical interface may be up/down depends on: Layer 1 connectivity Layer 2 line protocol Once physical interface is down, BGP peering sessions using that interface will be down. Loopback is a virtual interface, its state is always up. Eliminates dependency from physical interfaces and physical topology for establishing TCP connection. To configure loopback in RouterOS, create a bridge without any slave port, assign IP address to the bridge. /interface bridge add name=lo0 /ip address add address=10.1.1.1/32 interface=lo0 16 MTCINE Bootcamp + IPv6 Workshop LAB: IBGP PEERING lo0: 10.1.1.2 lo0: 10.1.1.1 AS100 172.16.1.1/24 eth1 R1 172.16.1.2/24 eth1 R2 10.88.0.0/24 Configure your routers according to the topology. Point static route or enable IGP between R1 and R2: [admin@R1] [admin@R2] # OR [admin@R1] [admin@R1] [admin@R2] [admin@R2] /ip route> add dst-address=10.1.1.2 gateway=172.16.1.2 /ip route> add dst-address=10.1.1.1 gateway=172.16.1.1 /routing /routing /routing /routing ospf ospf ospf ospf network> network> network> network> add add add add network=172.16.1.0/24 area=backbone network=10.1.1.1 area=backbone network=172.16.1.0/24 area=backbone network=10.1.1.2 area=backbone BGP peer configuration: [admin@R1] /routing bgp peer> add remote-address=10.1.1.2 \ remote-as=100 update-source=lo0 [admin@R2] /routing bgp peer> add remote-address=10.1.1.1 \ remote-as=100 update-source=lo0 LAB: EBGP MULTI-HOP WITH LOOPBACKS lo0: 10.1.1.1 AS100 R1 lo0: 10.1.1.2 172.16.1.1/24 eth1 172.16.1.2/24 eth1 eth2 172.16.2.1/24 eth2 172.16.2.2/24 AS200 R2 10.88.0.0/24 Configure your routers according to the topology. Point static routes so that the neighbors can reach each other: [admin@R1] /ip route> add dst-address=10.1.1.2 \ gateway=172.16.1.2,172.16.2.2 [admin@R2] /ip route> add dst-address=10.1.1.1 \ gateway=172.16.1.1,172.16.2.1 BGP peer configuration: [admin@R1] /routing bgp peer> add remote-address=10.1.1.2 \ remote-as=200 multihop=yes update-source=lo0 [admin@R2] /routing bgp peer> add remote-address=10.1.1.1 \ remote-as=100 multihop=yes update-source=lo0 17 MTCINE Bootcamp + IPv6 Workshop BGP BEST PATH Best path is the route that BGP selected to use in RIB. Path attributes are used to determine best path. Best path might not be the shortest path, but the most suitable path from the business point of view Administrator influent the selection process by routing policy BGP uses single best path to reach the destination. BGP always propagates the best path to the neighbors. BGP Multipath is a feature that allows BGP to install multiple best paths when they have the same metrics. For load sharing over multiple gateways RouterOS does not support BGP Multipath, peering with loopbacks to tweak BGP load sharing BEST PATH SELECTION 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. Nexthop must be reachable. Highest Weight (default 0). Highest Local Pref. (default 100). Shortest AS Path. Locally originated path (aggregated route or BGP network). Lowest origin type (IGP < EGP < Incomplete). Lowest MED (default 0). Prefer eBGP over iBGP. Lowest Router ID. Lowest Originator ID. Shortest route reflection cluster (default 0). Lowest neighbor address. 18 MTCINE Bootcamp + IPv6 Workshop BGP PATH ATTRIBUTES There are four categories of path attribute: Well-known mandatory Well-known discretionary This attribute must be recognized by all BGP implementations but does not have to be included in every BGP UPDATE message Optional transitive This attribute MUST exist in the BGP UPDATE. If this attribute is missing a NOTIFICATION error is generated and the session is closed If the attribute is not recognized by the BGP implementation but the transitive flag IS set the attribute should be accepted and passed along to other peers Optional non-transitive If the attribute is not recognized by the BGP implementation but the transitive flag IS NOT set the attribute should be ignored and not passed on to other peers BGP PATH ATTRIBUTES (CONT.) 19 MTCINE Bootcamp + IPv6 Workshop BGP PATH ATTRIBUTES (CONT.) Type Code (Decimal) Attribute Name 1 ORIGIN Category Well-known mandatory 2 AS_PATH Well-known mandatory 3 NEXT_HOP Well-known mandatory 4 MULTI_EXIT_DISC (MED) Optional non-transitive 5 LOCAL_PREF Well-known discretionary 6 ATOMIC_AGGREGATE Well-known discretionary 7 AGGREGATOR Optional transitive 8 COMMUNITY Optional transitive 9 ORIGINATOR_ID Optional non-transitive 10 Cluster List Optional non-transitive 14 Multiprotocol Reachable NLRI Optional non-transitive 15 Multiprotocol Unreachable NLRI Optional non-transitive NEXTHOP IP address that is used to reach a certain destination. For eBGP nexthop is neighbor's IP address. eBGP advertised nexthop is carried into iBGP. AS100 172.16.0.0/24 172.16.0.0/24 Nexthop: 10.1.1.1 172.16.0.0/24 Nexthop: 10.1.1.1 R1 10.1.1.1/30 10.1.1.2/30 R3 R2 lo0: 10.30.1.1 lo0: 10.30.1.2 AS200 20 MTCINE Bootcamp + IPv6 Workshop NEXTHOP SELF Force iBGP speaker to send its local peer address as nexthop. Use when P2P link between border router (R2) and eBGP peer (R1) is not advertised in IGP (OSPF/IS-IS). AS100 172.16.0.0/24 172.16.0.0/24 Nexthop: 10.1.1.1 172.16.0.0/24 Nexthop: 10.30.1.1 R1 10.1.1.1/30 10.1.1.2/30 R3 R2 lo0: 10.30.1.1 lo0: 10.30.1.2 AS200 [admin@R2] /routing bgp peer> set IBGP-R3-IPV4 nexthop-choice=force-self WEIGHT Weight is only significant locally to the router. This attribute is not advertised to any peer Use inbound filter to set weight Prefix without assigned weight has default value of 0. Path with higher weight is preferred. Weight is well-known AS200 AS100 as Cisco proprietary, R3 however MikroTik R1 RouterOS also implemented Weight. 10.1.1.0/24 10.1.1.0/24 R2 Weight: 100 Best Path Weight: 50 AS300 21 MTCINE Bootcamp + IPv6 Workshop LOCAL PREFERENCE Local Preference is only significant within local AS. This attribute is not advertised to eBGP peers Can be set by either inbound or outbound filter Indicates which path has preference to exit the AS. 10.1.1.0/24 Path with higher AS200 AS100 Local Pref. is preferred R5 R1 (default: 100). 10.1.1.0/24 Local Pref.: 200 Best Path AS300 R4 R2 R3 10.1.1.0/24 Local Pref.:100 10.1.1.0/24 via R2 AS PATH List of AS numbers that an update has traversed. AS300 R3 10.1.1.0/24 AS Path:200,100 AS400 R2 10.1.1.0/24 10.1.1.0/24 AS Path:100 AS100 R1 R4 AS200 10.1.1.0/24 AS Path: 300,200,100 Can be manipulated for traffic engineering. AS Path Prepending in outbound filter 22 MTCINE Bootcamp + IPv6 Workshop ORIGIN Information about how the prefix is originated into BGP. Prefers IGP over EGP, and EGP over Incomplete. IGP EGP Interior Gateway Protocol Prefix is fed into BGP by the network command Prefix learned via Exterior Gateway Protocol (now obsolete) Incomplete Origin is unknown Occurs when prefix is redistributed from other protocols into BGP Result of aggregation MED Multi Exit Discriminator or Metric, hint to external neighbor about path preference into an AS. Lower metric is preferred (Default: 0). Exchanged between AS and used to make decision inside that AS, not passed to third AS. Ignored if received from different ASes. IGP Metric is copied to MED when redistributed to BGP. 23 MTCINE Bootcamp + IPv6 Workshop MED (CONT.) 10.1.1.0/24 MED: 10 AS100 AS300 R4 R1 10.1.1.0/24 MED: 50 10.1.1.0/24 No MED 10.1.1.0/24 10.1.1.0/24 MED not advertised 10.1.1.0/24 MED: 100 R3 R2 AS200 • R1, R2 and R3 advertise the same network to R4 with different MED values. • R4 only compares MEDs coming from the same AS (R2 and R3). • MED coming from different AS (R1) is ignored. • Other attributes are used to select best path between AS100 and AS200. ROUTE DISTRIBUTION IGP (Connected, Static, RIP, OSPF) routes can be redistributed into BGP. /routing bgp instance set default redistribute-static=yes set default redistribute-ospf=yes Prefix origin is “incomplete”. Redistribution can be used for advertising supernet. Assign IP to loopback interface and redistribute connected Point an unreachable static route and redistribute static Risky to redistribute without filtering. Always use routing filters to avoid unwanted route advertisements. 24 MTCINE Bootcamp + IPv6 Workshop LAB: ROUTE DISTRIBUTION lo1: 10.200.0.1/22 lo2: 10.200.0.1/24 lo3: 10.200.1.1/24 lo4: 10.200.2.1/24 lo5: 10.200.3.1/24 AS100 Static Routes: 10.100.0.0/22 Unreachable 10.100.0.0/24 Unreachable 10.100.1.0/24 Unreachable 10.100.2.0/24 Unreachable 10.100.3.0/24 Unreachable Redistribute Static R1 ether1 172.16.1.1/24 ether1 172.16.1.2/24 AS200 R2 Redistribute Connected Configure your routers according to the topology. Do eBGP peering between AS100 and AS200. Redistribute static on R1. Redistribute connected on R2. [admin@R1] [admin@R1] [admin@R2] [admin@R2] /routing /routing /routing /routing bgp bgp bgp bgp instance> peer> add instance> peer> add set default as=100 redistribute-static=yes remote-address=172.16.1.2 remote-as=200 set default as=200 redistribute-connected=yes remote-address=172.16.1.1 remote-as=100 ROUTING FILTER Main tool to control and modify routing information. Organized in chains similar to firewall. Specify in BGP peer's configuration which chains to use or BGP instance out filter. Prefix passes instance chain, then moves to peer's chain. When applied at peer’s inbound direction, it will filter what prefixes you will get from your peer. When applied at BGP instance’s, or peer’s outbound direction, it will filter what you will advertise to your peer. 25 MTCINE Bootcamp + IPv6 Workshop PREFIX FILTERING Can be configured to receive specific prefixes from peer, or advertise specific prefixes to peer only. Similar to “ip prefix-list” in Cisco IOS. Prefixes can either be matched exactly or be matched by prefix length, for example: Accept only 10.200.0.0/22, discard others /routing filter add chain=EBGP-AS200-IPV4-IN prefix=10.200.0.0/22 action=accept add chain=EBGP-AS200-IPV4-IN action=discard Accept any prefixes that has prefix length from /22 to /24 in subnet 10.200.0.0/22, discard others /routing filter add chain=EBGP-AS200-IPV4-IN prefix=10.200.0.0/22 \ prefix-length=22-24 action=accept add chain=EBGP-AS200-IPV4-IN action=discard LAB: PREFIX FILTERING lo1: 10.200.0.1/22 lo2: 10.200.0.1/24 lo3: 10.200.1.1/24 lo4: 10.200.2.1/24 lo5: 10.200.3.1/24 AS100 Static Routes: 10.100.0.0/22 Unreachable 10.100.0.0/24 Unreachable 10.100.1.0/24 Unreachable 10.100.2.0/24 Unreachable 10.100.3.0/24 Unreachable Redistribute Static R1 ether1 172.16.1.1/24 ether1 172.16.1.2/24 AS200 R2 Redistribute Connected Configure prefix filtering on AS100 (R1): Accept only prefix 10.200.1.0/24, discard others Advertise only prefix 10.100.1.0/24, discard others [admin@R1] /routing bgp peer> set 0 in-filter=EBGP-AS200-IPV4-IN \ out-filter=EBGP-AS200-IPV4-OUT [admin@R1] /routing filter> add chain=EBGP-AS200-IPV4-IN prefix=10.200.1.0/24 action=accept add chain=EBGP-AS200-IPV4-IN action=discard add chain=EBGP-AS200-IPV4-OUT prefix=10.100.1.0/24 action=accept add chain=EBGP-AS200-IPV4-OUT action=discard 26 MTCINE Bootcamp + IPv6 Workshop AS PATH FILTERING Can be configured to receive prefixes from, or advertise prefixes to certain ASN only. Similar to “ip as-path access-list” in Cisco IOS. Supports regular expressions: “.” – Any single character “^” – Start of the AS Path “$” – End of the AS Path “_” – matches comma, space, start and end of AS Path LAB: AS PATH FILTERING lo0: 10.200.0.1/22 lo1: 10.200.1.1/24 lo2: 10.200.2.1/24 lo3: 10.200.3.1/24 lo4: 10.200.4.1/24 AS100 Static Routes: 10.100.0.0/22 Unreachable 10.100.0.0/24 Unreachable 10.100.1.0/24 Unreachable 10.100.2.0/24 Unreachable 10.100.3.0/24 Unreachable Redistribute Static R1 ether2 172.16.1.1/24 ether2 172.16.1.2/24 AS200 R2 Redistribute Connected Configure AS Path filtering on AS200 (R2): Accept only prefixes originated from AS100, discard others Advertise only prefixes locally originated, discard others [admin@R2] /routing bgp peer> set 0 in-filter=EBGP-AS100-IPV4-IN \ out-filter=EBGP-AS100-IPV4-OUT [admin@R2] /routing filter> add chain=EBGP-AS100-IPV4-IN bgp-as-path=“_100\$” action=accept add chain=EBGP-AS100-IPV4-IN action=discard add chain=EBGP-AS100-IPV4-OUT bgp-as-path=“^\$” action=accept add chain=EBGP-AS100-IPV4-OUT action=discard 27 MTCINE Bootcamp + IPv6 Workshop SET ADVERTISED BGP ATTRIBUTES In order to manipulate inbound traffic, you can set BGP attributes of advertised routes using outbound routing filter: Advertise MED as 5 to manipulate peer AS not to prefer this path among all paths they received from your AS. /routing filter add chain=EBGP-AS100-IPV4-OUT prefix=10.100.0.0/24 \ set-bgp-med=5 action=accept Prepend AS Path 3 times to manipulate peer AS not to prefer this path among all paths they received from different ASes. /routing filter add chain=EBGP-AS100-IPV4-OUT prefix=10.100.0.0/24 \ set-bgp-prepend=3 action=accept RouterOS’ AS Path prepending behavior differs from Cisco IOS’: In RouterOS, prepending AS100 3 times, AS Path: 100,100,100 In IOS, prepending AS100 3 times, AS Path: 100,100,100,100 BGP SOFT RECONFIGURATION When “action=discard” is used, routes are not updated after filter change. Solutions: 1. Use “action=reject” to keep routes in the memory Similar result to “neighbor X.X.X.X soft-reconfiguration inbound” command in Cisco IOS /routing filter add chain=EBGP-AS200-IPV4-IN prefix=10.200.0.0/22 action=accept add chain=EBGP-AS200-IPV4-IN action=reject 2. Dynamic (Peer must support Refresh Capability): Peer refreshes the routes after the changes are done No additional memory is used It is not done automatically – need to run “Refresh” command 28 MTCINE Bootcamp + IPv6 Workshop LAB: BGP TRAFFIC ENGINEERING Set next-hop-self on all iBGP sessions. Use AS Path Prepending to manipulate outbound traffic: From AS99 to AS200’s prefixes via AS100 From AS99 to AS100’s prefixes via AS200 LAB: BGP TRAFFIC ENGINEERING (CONT.) Configuration requirements: R1 R2 iBGP with R2 eBGP with R3 R9 iBGP with R1 eBGP with R4 R4 iBGP with R4 eBGP with R9, use “set-bgp-prepend=3” in outbound filter R3 iBGP with R3 eBGP with R9, use “set-bgp-prepend=3” in outbound filter eBGP with R1 and R2 Traceroute from AS99 to AS100 and AS200 for verification. 29 MTCINE Bootcamp + IPv6 Workshop PREFIX AGGREGATION Summarization of more specific routes into supernet. Can be used to hide topology. AS100 Works only on the same instance BGP routes. AS400 R4 10.1.1.0/24 10.0.0.0/8 R1 AS300 R3 10.1.2.0/24 AS200 R2 [admin@R3] /routing bgp aggregate> add instance=default \ prefix=10.0.0.0/8 summary-only=yes inherit-attributes=no SERVICE PROVIDER BGP DESIGN Route Reflector Confederation Multi-homing BGP Community ISP Routing Policies 30 MTCINE Bootcamp + IPv6 Workshop BGP ROUTE REFLECTOR Due to the nature of full mesh iBGP is required, when there are many BGP routers in the network, it could result huge amount of iBGP sessions, which is hard to maintain and troubleshoot. Sessions: n(n-1)/2 10 routers = 45 sessions, 50 routers = 1,225 sessions Route Reflector can re-advertise iBGP routes to avoid full mesh. Reduces communication messages. Minimizes amount of data per message: Only best path is reflected RouterOS cannot be configured as pure route reflector. Routes must be installed to RIB to be reflected to other client ROUTE REFLECTOR CONFIGURATION AS200 AS200 R3 R1 R2 R1 R3 R2 RR Route Reflector (RR) is configured by: Enabling “client-to-client-reflection” on BGP instance Enabling “route-reflect” on appropriate RR client peer There is no difference in RR client’s configuration [admin@R2] /routing bgp instance> set default client-to-client-reflection=yes [admin@R2] /routing bgp peer> set IBGP-R1-IPV4 route-reflect=yes 31 MTCINE Bootcamp + IPv6 Workshop LAB: ROUTE REFLECTOR 1. 2. Configure iBGP full mesh and advertise all customer LANs into iBGP, then test connectivity between LANs. Configure Route Reflectors to eliminate iBGP full mesh session, then test connectivity between LANs again. BGP CONFEDERATION Confederation is another solution for avoiding iBGP full mesh. Divides AS into multiple confederation ASes. To outside world confederation appears as single AS. iBGP in Each AS must be fully meshed (or use RRs). eBGP between confederation ASes: Similar to iBGP behavior, nexthop is unchanged AS Path inside confederation is in scopes: (30,20) 32 MTCINE Bootcamp + IPv6 Workshop CONFEDERATION SETUP AS200 R9 AS300 AS Path: 100,300 R8 R4 R3 R1 AS10 AS20 AS Path: (20,30) R5 R2 AS400 AS100 R6 AS30 R7 /routing bgp instance set default as=10 confederation=100 \ confederation-peers=10,20,30 SINGLE-HOMED Stub network, has only one connection to the outside world. Typically private ASN is used (64512-65534). Upstream ISP originates only default route. Upstream ISP advertises networks. Has the same routing policy as ISP. Actually not necessary to run BGP. ISP 0.0.0.0/0 Single-homed Customer 172.16.0.0/16 AS65500 Global Internet AS300 172.16.0.0/24 33 MTCINE Bootcamp + IPv6 Workshop DUAL-HOMED Stub network, has multiple connections to single ISP. Typically private ASN is used (64512-65534). Receive default route or full route from upstream ISP. Upstream ISP advertises networks. Has the same routing policy as ISP. Use BGP to do load sharing or fail-over. Dual-homed Customer ISP 172.16.0.0/16 AS65500 Global Internet 172.16.0.0/24 AS300 PRIVATE AS REMOVAL Global Internet AS65500 172.16.0.0/16 Private AS cannot be leaked to public Available for eBGP neighbors Announce only aggregate route Use following command: ISP 172.16.0.0/24 AS65501 172.16.1.0/24 AS300 AS65502 172.16.2.0/24 /routing bgp peer set <peer-name> remove-private-as=yes 34 MTCINE Bootcamp + IPv6 Workshop MULTI-HOMED Needs to request own IP/ASN from: Upstream ISP Local Internet Registry (LIR) Global Internet Regional Internet Registry (RIR) JPNIC, CNNIC, SGNIC…etc. APNIC, ARIN, RIPE NCC…etc. Typically receive full route AS100 from upstream ISPs. R1 Advertise own address space to upstream ISPs. Supports independent routing policies. Use BGP to do load sharing or fail-over. AS200 R3 R2 AS300 BGP & CONNECTION TRACKING Connection tracking is unable to keep valid track of connections with multi-homed BGP network. Packets related to one connection can travel through different paths. Asymmetric routing usually happens in multi-homed BGP networks. Outbound through ISP 1 Inbound through ISP 2 Do not drop “invalid” connections in firewall. Connection Tracking should be turned off for better performance. 35 MTCINE Bootcamp + IPv6 Workshop BGP COMMUNITY Attribute that groups prefixes for informational or implementing routing policies. 32-bit value, written in format “XX:YY” Provide extra information about the prefix, for instance: “<ASN>:100” = Customer routes “<ASN>:200” = Prefixes from private peering or Internet eXchange (IX) “<ASN>:300” = Internet prefixes from upstream provider Filters can be easily applied to whole group Default BGP Communities: no-export – do not advertise to eBGP peer no-advertise – do not advertise to any peer internet – advertise to Internet community local-as – do not send outside local AS (in non-confederation network the same as no-export) BGP COMMUNITY – USE CASE There are three common use cases of BGP Community in current industry: Informational Traffic Engineering Instruct upstream provider to implement specific routing policy, such as: set Local Pref., AS Path prepending, do not advertise to specific link or peer…etc., sent by downstream customer Blackhole provide information about origin of the route, such as: location, network name, relationship (customer, peer, upstream), sent by upstream provider Instruct upstream provider to blackhole a specific route (typically /32), used when being DoS attacked. Some carriers offer BGP Community support in their IP Transit service. 36 MTCINE Bootcamp + IPv6 Workshop BGP COMMUNITY – EXAMPLE 1 Assume that you don't want AS200 (R2) to propagate routes learned from AS100 (R1). 10.1.1.0/24 AS100 AS300 R3 AS200 R1 R2 [admin@R1] /routing bgp peer> set 0 out-filter=EBGP-AS200-IPV4-OUT [admin@R1] /routing filter> add chain=EBGP-AS200-IPV4-OUT \ action=accept set-bgp-communities=no-export BGP COMMUNITY – EXAMPLE 2 AS100 defined traffic engineering BGP Communities for downstream customers: 100:500 – advertise to all peers 100:501 – advertise to AS400 only 10.1.1.0/24 community=100:500 10.2.2.0/24 community=100:501 AS 400 ISP AS100 AS300 AS 500 37 MTCINE Bootcamp + IPv6 Workshop BGP EXTENDED COMMUNITY Used to carry additional fields in L2VPN and VPNv4 setups. Length is 64-bit, written in format “TT:XX:YY”, for instance, RT:132730:100. Some additional fields carried: Route Targets Site of Origin Control flags MTU Encapsulation flags ISP ROUTING POLICIES There are some best common practices for ISP. To upstream providers: To downstream customers: Advertise only your own prefixes and your customer prefixes Advertise aggregation to all providers, /24s to specific provider Use BGP Community for traffic engineering if your upstream provider supports, avoid de-aggregation as much as possible Do inbound filtering, accept only authorized prefixes To peers: Advertise only your own prefixes and your customer prefixes Never leak peer’s prefixes to other peers or any of your upstream providers 38 MTCINE Bootcamp + IPv6 Workshop MULTIPROTOCOL LABEL SWITCHING (MPLS) Introduction to MPLS Static Label Mapping Label Distribution Protocol (LDP) Label Binding Filtering Traceroute in MPLS MPLS LAB SETUP Run OSPF on all router’s P2P links. Run iBGP with Route Reflectors, advertise LAN networks into iBGP, make sure reachability between LANs. 39 MTCINE Bootcamp + IPv6 Workshop MPLS LAB SETUP (CONT.) Reset router's configuration. Set up configuration as illustrated. Create bridge interface and add loopback addresses. Run OSPF on all router point-to-point links. Advertise loopback addresses into OSPF. INTRODUCTION TO MPLS Stands for Multiprotocol Label Switching. Technology used to forward packets, based on short labels. Initial goal: more efficient forwarding than IP routing (similar to ATM switching). Serves as foundation for some “Advanced Services”: Layer3 VPN Layer2 VPN, Any Transport over MPLS (AToM) MPLS Traffic Engineering Guaranteed bandwidth services 40 MTCINE Bootcamp + IPv6 Workshop MPLS BASICS (CONT.) LER – Label Edge Router or Provider Edge router (PE) LSR – Label Switch Router or Provider router (P) LSP – Label Switched Path Packets are classified and labeled at ingress LER LSRs forward packets using label swapping Label is removed at egress LER MPLS Backbone MPLS BASICS (CONT.) Also called 2.5 layer protocol. Shim header (32-bit) placed between OSI Layer 2 and Layer 3. Multiple labels can be used for MPLS packet encapsulation After Layer 2 header and before Layer 3 header Creation of a label stack MPLS Label format: Label (20 bits) EXP (3 bits) End of stack flag (1 bit) TTL (8 bits) For QoS enforcement L2 MPLS Label L3 EXP S TTL Whether current label is the last in the stack 41 MTCINE Bootcamp + IPv6 Workshop MPLS BASICS (CONT.) LSRs always use the top label of the stack. Several Label distribution methods exist: Static label mapping LDP – maps IGP unicast route into label BGP – VPN labels for L3VPN and L2VPN RSVP, CR-LDP – used for traffic engineering and resource reservation STATIC LABEL MAPPING RouterOS allows to add static local and remote bindings for every destination. MPLS dynamic label range must be adjusted to free labels for static bindings. /mpls /mpls /mpls /mpls set dynamic-label-range=1000-1048575 local-bindings remote-bindings forwarding-table 42 MTCINE Bootcamp + IPv6 Workshop STATIC LABEL MAPPING – EXAMPLE Local: Remote: Fwd: lo0:1.1.1.1 lo0:2.2.2.2 lo0:3.3.3.3 R1 R2 R3 DST 1.1.1.1 2.2.2.2 3.3.3.3 LABEL impl-null 22 23 DST 1.1.1.1 2.2.2.2 3.3.3.3 LABEL 21 impl-null 23 DST 1.1.1.1 2.2.2.2 3.3.3.3 LABEL 21 22 impl-null DST 2.2.2.2 3.3.3.3 HOP LABEL R2 impl-null R2 23 DST 1.1.1.1 3.3.3.3 HOP LABEL R1 impl-null R3 impl-null DST 2.2.2.2 1.1.1.1 HOP LABEL R2 impl-null R2 21 IN 22 23 OUT DST 2.2.2.2 23 3.3.3.3 IN 21 23 OUT DST 1.1.1.1 3.3.3.3 IN 21 22 OUT DST 21 1.1.1.1 2.2.2.2 LAB: STATIC LABEL MAPPING Create static label bindings for R2 to reach R1 loopback. Since ECMP is not used in label binding, choose only first gateway Disable link between R2-R9 for configuration simplicity [admin@R2] /mpls local-bindings> add dst-address=10.1.1.1 label=201 [admin@R2] /mpls remote-bindings> add dst-address=10.1.1.1 \ nexthop=10.2.4.4 label=401 [admin@R4] /mpls local-bindings> add dst-address=10.1.1.1 label=401 [admin@R4] /mpls remote-bindings> add dst-address=10.1.1.1 \ nexthop=10.3.4.3 label=301 [admin@R3] /mpls local-bindings> add dst-address=10.1.1.1 label=301 [admin@R3] /mpls remote-bindings> add dst-address=10.1.1.1 \ nexthop=10.1.3.1 label=impl-null [admin@R1] /mpls local-bindings> add dst-address=10.1.1.1 \ label=impl-null Test if labels are set with traceroute. [admin@R2] > /tool traceroute 10.1.1.1 src-address=10.1.1.2 43 MTCINE Bootcamp + IPv6 Workshop LABEL DISTRIBUTION PROTOCOL (LDP) LDP is used for creating a local label binding to each IP prefix in IGP and distributes to LDP neighbors. More effective and flexible compared to static mapping. Commonly used in most MPLS network. Remote bindings IGP Prefix 10.1.1.0/24 10.1.1.0/24 Label 21 Local binding Label 21 10.1.1.0/24 Label 22 Local binding Label 22 10.1.1.0/24 Label 23 Local binding Label 23 LABEL DISTRIBUTION PROTOCOL (LDP) (CONT.) LDP Hello messages – UDP port 646. Hellos are sent to “all routers in this subnet” multicast address (224.0.0.2) LDP transport session establishment – TCP port 646. Label distribution modes: Downstream-on-Demand (DoD) – each LSR requests its next-hop label binding (Not yet implemented) Unsolicited Downstream (UD) – LSR distributes a binding all adjacent LSRs even if LSRs are requesting a label Configuring LDP transport and interface. [admin@R1] /mpls ldp> set enabled=yes \ transport-address=10.1.1.1 lsr-id=10.1.1.1 [admin@R1] /mpls ldp interface> add interface=ether1 44 MTCINE Bootcamp + IPv6 Workshop LAB: LDP Remove all static mappings from previous lab. Enable LDP and set LSR ID and transport address the same as loopback address. [admin@R2] /mpls ldp> set enabled=yes \ transport-address=10.1.1.2 lsr-id=10.1.1.2 Add LDP interfaces connecting neighbor routers. [admin@R2] /mpls ldp interface> add interface=ether1 [admin@R2] /mpls ldp interface> add interface=ether2 Verify if LDP neighbors are created. [admin@R2] > /mpls ldp neighbor print Check MPLS forwarding table. [admin@R2] > /mpls forwarding-table print Do traceroute between router loopbacks. LABEL SPACE Per interface label space. Packet is forwarded based on both the incoming interface and the label Per platform label space. Label is not unique per interface Label1 Path 1 Path 1 Label1 Path 1 Path 1 Path 2 Label1 Path 2 Label1 Path 1 45 MTCINE Bootcamp + IPv6 Workshop RESERVED LABELS Default label range is 16-1048575. Labels from 0 to 15 are reserved, but only 4 are used at this point: 0 – explicit NULL 1 – router alert 2 – IPv6 explicit NULL 3 – implicit NULL PENULTIMATE HOP POPPING (PHP) Router is egress point for network that is directly connected to it, next hop for traffic is not MPLS router. Advertised with “implicit null” label. Penultimate Hop Popping ensures that routers do not have to do unnecessary label lookup when it is known in advance that router will have to route packet natively. Setting transport address ensures proper Penultimate Hop Popping (PHP) behavior. 46 MTCINE Bootcamp + IPv6 Workshop PENULTIMATE HOP POPPING (PHP) (CONT.) PHP Implicit NULL 0 PHP Explicit NULL EXPLICIT NULL If configured, penultimate LSR forwards packet with NULL label, instead of popping stack. Useful to preserve QoS. Not required if stack contains at least two labels (inner label can still carry QoS value). Implicit NULL is used by default. 47 MTCINE Bootcamp + IPv6 Workshop TARGETED LDP In some cases it is necessary to set up targeted LDP session. Session between not directly connected LSRs Targeted LDP is used to establish a Traffic Engineering (TE) tunnel Configuration: /mpls ldp neighbor add transport=<REMOTE_IP> send-targeted=yes Targeted LDP LDP LDP LDP LABEL BINDING FILTERING Can be used to distribute only specified sets of labels to reduce resource usage Two types of binding filters: Which bindings should be advertised Which bindings should be accepted Configure in “/mpls ldp advertise-filter” Configure in “/mpls ldp accept-filter” Filters are applied only to incoming/outgoing advertisements. Any changes to filters requires to disable and re-enable LDP. /mpls ldp advertise-filter add prefix=9.9.9.0/24 advertise=yes add prefix=0.0.0.0/0 advertise=no 48 MTCINE Bootcamp + IPv6 Workshop LAB: LABEL BINDING FILTERING Set up label binding filters so that only bindings to loopback addresses from your group are sent and received. [admin@R2] /mpls ldp accept-filter> add prefix=10.1.1.0/24 accept=yes add prefix=0.0.0.0/0 accept=no [admin@R2] /mpls ldp advertise-filter> add prefix=10.1.1.0/24 advertise=yes add prefix=0.0.0.0/0 advertise=no Check forwarding table to make sure filters worked. [admin@R2] > /mpls forwarding-table print Check if packets are label switched or L3 forwarded with traceroute . [admin@R2] > /tool traceroute 10.1.1.1 src-address=10.1.1.2 TRACEROUTE IN MPLS ICMP error messages are switched further along LSP. It will cause false increase in latency for that hop. Label: 12 R1 Label: 23 R2 Label: 34 R3 Label: 32 R4 Label: 43 49 MTCINE Bootcamp + IPv6 Workshop MPLS LAYER 3 VPN Virtual Routing and Forwarding (VRF) Multiprotocol BGP (MP-BGP) Route Distinguisher Route Target PE-CE Routing Protocols MPLS L3VPN MPLS Layer 3 VPN is also known as IPVPN. Service provider participates in customer routing. Service provider takes care of convergence and fail-over. Offers more flexibility and reliability compared to traditional overlay and peer-to-peer VPNs. Ease of service provision and maintenance Cost effective and scalable Can employ high availability and bandwidth-guarantee SLA Service provider network MUST be MPLS enabled. PE (Provider Edge) is a provider router that connecting to customer site. CE (Customer Edge) is a customer router that connecting to provider. 50 MTCINE Bootcamp + IPv6 Workshop MPLS L3VPN (CONT.) VPN A Site 1 RR CE CE VPN B Site 2 PE PE CE CE PE VPN B Site 1 VPN A Site 2 CE iBGP VPNv4 OSPF/BGP CE-PE VPN B Site 3 VPN A Site 3 L3VPN BUILDING BLOCKS Multiprotocol BGP (MP-BGP) is used to distribute VPN prefixes and labels between PEs. PE-CE Routing Protocols: VPNv4 Address Family Static Route OSPF BGP Key Components: Virtual Routing and Forwarding (VRF) Route Distinguisher Route Targets 51 MTCINE Bootcamp + IPv6 Workshop VRF Stands for Virtual Routing and Forwarding. Functionality of completely independent routing tables on one router. Routing tables can be used for Policy Based Routing (PBR). Multiple VRFs solves the problem of overlapping customer IP prefixes. Different customers can use the same IP address When nexthop resolving fails it is not resolved in main table (compared to PBR). Any router management (Winbox, telnet, SSH...etc.) is not possible from VRF interface. Ping and traceroute tools are updated to support VRFs. VRF CONFIGURATION Create VRF and add interface to VRF: /ip route vrf add routing-mark=VPN-A interfaces=ether4 Route leaking is route exchange between separate VRFs. Static inter-VRF route: Explicitly specified routing table (works with “main”) /ip route add dst-address=5.5.5.0/24 \ gateway=10.3.0.1@main routing-mark=VPN-A Explicitly specify interface /ip route add dst-address=5.5.5.0/24 \ gateway=10.3.0.1%ether2 routing-mark=VPN-A 52 MTCINE Bootcamp + IPv6 Workshop MULTIPROTOCOL BGP (MP-BGP) BGP was initially designed for IPv4 routing. While more and more requirements of supporting new address types, and considering ease of management and operations, BGP was developed into MP-BGP, Address Family attribute was introduced to carry new types of address. Due to nature of BGP’s TLV packet format, the protocol is very extensible for supporting new features. RouterOS supported Address Families: IPv4 IPv6 L2VPN VPNv4 Cisco Style L2VPN ROUTE DISTINGUISHER Route distinguisher (RD) is used to make IPv4 prefixes unique when advertised into VPNv4 address family. Format: 64-bit length RD + IPv4 prefix = VPNv4 prefix (96-bit), so that different customers can use overlapping addresses <IP>:<Unique Number> <ASN>:<Unique Number> RD has to be configured in appropriate VRF for VPNv4 to work. Normally one RD per VPN customer. Some complex VPN scenarios may require more than one RD. Load balancing to dual-homed VPN sites 53 MTCINE Bootcamp + IPv6 Workshop ROUTE TARGET Route Target (RT) identifies which VRF(s) keep which VPN prefixes. RT is an 8-byte BGP Extended Community attribute. Each VRF in PE is configured with a set of Route Targets. Import and Export Route Targets must be the same for anyto-any IPVPN Different Import/Export Route Targets for hub-and-spoke IPVPN topology Export Route Target values are attached to VPNv4 prefixes advertisements. ROUTE TARGET (CONT.) Use RTs to determine which prefixes should be imported for which VPN sites. VPN B Import: 200:1 Export: 200:1 VPN A Site 1 CE Import: 100:1 Export: 100:1 CE Site 1 PE2 PE1 Import: 100:1 PE3 Export: 100:1 PE4 VPN B Site 2 CE Import: 200:1 Export: 200:1 CE VPN A Site 2 54 MTCINE Bootcamp + IPv6 Workshop CONFIGURING L3VPN Create VRF instance. /ip route vrf add routing-mark=VPN-A \ route-distinguisher=100:1 \ import-route-targets=100:1 \ export-route-targets=100:1 Configure BGP to use VRF and VPNv4 Address Family. OSPF as PE-CE routing protocol /routing bgp instance vrf add instance=default \ routing-mark=VPN-A \ redistribute-connected=yes \ redistribute-ospf=yes /routing bgp peer add name=IBGP-R3-VPNV4 \ remote-as=100 remote-address=10.1.1.3 \ address-families=vpnv4 update-source=lo0 Results /routing bgp vpnv4-route print PE-CE ROUTING PROTOCOLS Static Route as PE-CE Technically static route can be used between PE-CE, however this leads to too much administrative overhead CE needs to configure static routes manually for each destination /ip route add dst-address=10.200.1.0/24 gateway=10.100.1.2 \ routing-mark=VPN-A OSPF as PE-CE Enable VRF-aware OSPF, redistribute VPNv4 routes into OSPF /routing ospf instance set default \ routing-table=VPN-A redistribute-bgp=as-type-2 BGP as PE-CE (Recommended) Eliminate the need of route redistribution Provides more controls on filtering and policy implementation /routing bgp instance add name=VPNV4-VPN-A as=100 \ routing-table=VPN-A 55 MTCINE Bootcamp + IPv6 Workshop LAB: MPLS L3VPN LAB: MPLS L3VPN (CONT.) This lab is based on “MPLS Lab Setup” full scale lab topology. The purpose of this lab is to provide MPLS L3VPN (a.k.a IPVPN) to customers with our MPLS backbone. Green Customer Sites Blue Customer Sites Red Datacenter as Extranet VPN rules: All Green sites should HAVE access to other Green sites All Blue sites should HAVE access to other Blue sites Green sites and Blue sites should NOT have access to each other Green sites and Blue sites should BOTH have access to Red Extranet 56 MTCINE Bootcamp + IPv6 Workshop LAB: MPLS L3VPN (CONT.) Add a CE router between your PC and PE. Configure your PC to use the CE router as default gateway. Configure PE routers according to instruction on diagram. VRF, RD, Import/Export RTs PE-CE routing protocol (in VRF) PE advertises PE-CE link VPNv4 BGP sessions Route redistribution between PE-CE routing protocol and VPNv4 Configure CE routers according to instruction on diagram. PE-CE routing protocol (regular) CE advertises Customer LAN MPLS LAYER 2 VPN Virtual Private LAN Services (VPLS) Pseudowire LDP Based VPLS BGP Based VPLS MPLS MTU 57 MTCINE Bootcamp + IPv6 Workshop VIRTUAL PRIVATE LAN SERVICES (VPLS) MPLS L2VPN in RouterOS is mainly about VPLS Virtual Private LAN Services There are some other technologies in other vendor’s implementations, such as: AToM in Cisco IOS Glues together individual LANs across MPLS Two deployment options: LDP Based VPLS BGP Based VPLS Manual Discovery LDP Signaling (RFC 4762) BGP Discovery (RFC 6074) BGP Signaling (RFC 4761) L2VPNs are built with Pseudowire technology. VIRTUAL PRIVATE LAN SERVICES (VPLS) (CONT.) PW Label Customer's L2 frame Transport Label L2 header Site 1 CE1 PE1 PE2 Site 3 P1 CE3 PE3 MPLS backbone Pseudowire Site 2 CE2 CE – Customer's edge router PE – Provider’s edge router P – Provider's core router 58 MTCINE Bootcamp + IPv6 Workshop VPLS BUILDING BLOCKS LDP or MP-BGP is used to distribute pseudowire labels between PEs. PE-CE Attachment Circuit (AC): LDP Based VPLS uses Targeted LDP BGP Based VPLS uses L2VPN Address Family Ethernet type media Key Components: Pseudowire Control Word (CW) PSEUDOWIRE Pseudowire provides a common intermediate format to transport multiple types of network services over a Packet Switched Network (PSN). Pseudowire de-multiplexor field (PW Label) is used to identify VPLS tunnel. Pseudowire has MAC learning, flooding and forwarding functionality. Pseudowire technology provides Like-to-Like transport and also Interworking (IW). RouterOS does not have Interworking implementation, since it supports only VPLS, which is Ethernet type media 59 MTCINE Bootcamp + IPv6 Workshop LDP BASED VPLS Create VPLS tunnels on PEs, requires full mesh: /interface vpls add name=VPLS-A-R3 remote-peer=10.1.1.3 vpls-id=100:13 add name=VPLS-A-R5 remote-peer=10.1.1.5 vpls-id=100:15 Dynamic targeted LDP neighbor is added. VPLS tunnel ID must be unique for every VPLS. Related VPLS tunnel information can be viewed by: “/interface vpls monitor” command. Bridge VPLS interface with local one to provide transparent connectivity. /interface bridge add name=BR-VPLS-A /interface bridge port add interface=ether4 bridge=BR-VPLS-A add interface=VPLS-A-R3 bridge=BR-VPLS-A add interface=VPLS-A-R5 bridge=BR-VPLS-A BRIDGE HORIZON Forward Ethernet frame coming from PE to connected CEs. Packets are not forwarded to interfaces with the same horizon value. Horizon value is set in bridge port configuration. [admin@PE-2] /interface bridge port> add interface=VPLS-A-PE1 bridge=BR-VPLS-A horizon=1 add interface=VPLS-A-PE3 bridge=BR-VPLS-A horizon=1 CE1 CE3 PE1 1 PE3 1 CE2 1 1 CE4 PE2 60 MTCINE Bootcamp + IPv6 Workshop LAB: LDP BASED VPLS LAB: LDP BASED VPLS (CONT.) This lab is based on “MPLS Lab Setup” full scale lab topology. The purpose of this lab is to provide MPLS L2VPN (a.k.a Metro Ethernet) to customers with our MPLS backbone. VPN rules: All customer sites should be connected as single broadcast domain Layer 2 traffic between sites should be sent/received directly Internet access must go through HQ router, which has DHCP server, firewall, and bandwidth management policies Configure PE routers according to instruction on diagram. Full mesh Pseudowires between PEs Bridge Pseudowires and Attachment Circuit Enable RSTP on the Bridge 61 MTCINE Bootcamp + IPv6 Workshop LAB: LDP BASED VPLS (CONT.) Remove IP address on your PC NIC, set it as DHCP client. Make sure you got IP address from DHCP server at HQ. Send traffic between PCs, and monitor traffic pattern. Test Internet connectivity. You may realize some traffic paths are sub-optimal, frames are forwarded to RSTP Root Bridge PE before going to destination PE. Try to eliminate RSTP by using Bridge Horizon value, then monitor the traffic pattern again. BGP BASED VPLS LDP Based VPLS Drawbacks: Scalability issues due to static nature. Requirement to maintain full mesh of pseudowires. Configuration adjustment on all routers forming VPLS. BGP VPLS functionality Auto Discovery – No need to configure each VPLS router Signaling – Labels for VPLS tunnels distributed in BGP updates No need for targeted LDP sessions. No scalability issues. No significant advantages over LDP in case of full mesh iBGP. 62 MTCINE Bootcamp + IPv6 Workshop BGP BASED VPLS (CONT.) iBGP full mesh or use RR. Address Family L2VPN /routing bgp peer add remote address=10.1.1.2 remote-as=100 \ update-source=lo address-families=l2vpn Create VPN bridge. /interface bridge add name=BR-VPLS-A Configure BGP signaled VPLS interface. /interface vpls bgp-vpls add bridge=BR-VPLS-A bridge-horizon=1 \ site-id=1 route-distinguisher=1:1 \ import-route-targer=1:1 export-route-target=1:1 Route Distinguisher – Value that gets attached to VPLS NLRI to distinguish advertisements, value should be unique for each VPLS Import/Export Route Targets – Determine pseudowire mappings Site ID – Unique setting among members of particular VPLS LAB: BGP BASED VPLS 63 MTCINE Bootcamp + IPv6 Workshop LAB: BGP BASED VPLS (CONT.) This lab is based on “LDP Based VPLS” full scale lab topology. The purpose of this lab is the same as “LDP Based VPLS”, and VPN rules are the same. But this time we will use BGP to automate Pseudowire discovery and signaling. Make sure you got IP address from DHCP Server at HQ. Send traffic between PCs, and monitor traffic pattern. Test Internet connectivity. MPLS MTU MPLS MTU = IP MTU (L3) + MPLS headers. MPLS MTU is adjustable from “/mpls interface” menu. Default: 1508 If MTU is too large and next header is IP. Then generate “ICMP Need Fragment” error Else silently discard packet Eth(14) VLAN(4) MPLS(4) IP(20) DATA(1480) IP (L3) MTU MPLS MTU L2 MTU Full Frame 64 MTCINE Bootcamp + IPv6 Workshop VPLS L2MTU L2MTU: 1500 Eth(14) IP(20) DATA(1480) R1 L2MTU: 1526 Eth(14) MPLS(4) VPLS(4) CW(4) Eth(14) IP(20) DATA(1480) R2 L2MTU: 1526 Eth(14) MPLS(4) VPLS(4) CW(4) Eth(14) IP(20) DATA(1480) R3 L2MTU: 1522 Eth(14) VPLS(4) CW(4) Eth(14) IP(20) DATA(1480) R4 L2MTU: 1500 Eth(14) IP(20) DATA(1480) CONTROL WORD (CW) 4-byte Control Word (CW) is used for packet fragmentation and reassembly inside VPLS tunnel. Optional CW is added between PW Label and packet payload. CW can be turned off for compatibility with other vendors (Cisco BGP based VPLS). 65 MTCINE Bootcamp + IPv6 Workshop TRAFFIC ENGINEERING (TE) IP Routing Limitation Resource Reservation Protocol Traffic Engineering extension (RSVP-TE) Constrained Shortest Path First (CSPF) Static Tunnel Path Auto Bandwidth IP ROUTING LIMITATION Traditional IP routing decision is based on packet destination IP address. After two IP traffic flows for the same destination are merged, it is technically hard to split them and reroute over different paths. Overloaded link from Router C to Router E. A E C F D 50Mbps traffic from A to F B 50Mbps traffic from B to F 66 MTCINE Bootcamp + IPv6 Workshop TRAFFIC ENGINEERING (TE) MPLS Traffic Engineering (TE) solves the problem. Can be used to steer traffic to less utilized links. Constraint based routing – Path for the traffic flow is shortest path that meets resource requirements (constraints). Upgrade of congestion link can be delayed. TE can also reserve bandwidth for specific service level. A E C F D B TE Tunnel1 50Mbps TE Tunnel2 50Mbps HOW TE WORKS? TE establishes/maintains the tunnel using RSVP-TE. Resource Reservation Protocol Traffic Engineering extension Tunnel path at any point is determined based on network resources and tunnel requirements. Available resources are flooded via OSPF. Tunnel paths are calculated at the tunnel head-end based on a fit between required and available resources (constraint-based routing). TE tunnels are unidirectional. 67 MTCINE Bootcamp + IPv6 Workshop HOW TE WORKS? (CONT.) Tunnel head-end appears as TE interface. Auto TE works within the range of one OSPF area. Traffic can be forwarded automatically to TE if: Remote endpoint of pseudowire is the same as TE endpoint. BGP nexthop is tunnel endpoint. Can be turned off by setting “use-te-nexthop=no” in Routing Filter RSVP-TE Tunnel signaled with TE extensions to RSVP. Soft state maintained with downstream PATH messages. Soft state maintained with upstream RESV messages. New RSVP objects LABEL_REQUEST (PATH) LABEL (RESV) EXPLICIT_ROUTE RECORD_ROUTE (PATH/RESV) SESSION_ATTRIBUTE (PATH) MPLS Forwading table populated using RSVP labels allocated by RESV messages. 68 MTCINE Bootcamp + IPv6 Workshop TUNNEL PATH OPTION Tunnel path is routed based on routing table. Statically configured explicit path. Tunnel path: use-cspf=no and empty hops Tunnel path: use-cspf=no hops=<explicit hops config> Constrained Shortest Path First (CSPF) – head end router calculates path to tail end using knowledge of network state. Needs assistance form IGP. Tunnel path: use-cspf=yes, empty hops or explicitly configured hops TUNNEL PATH HOPS Static path is established by setting strict or loose hops: Strict – Defines that there must not be any other hops between previous hop and "strict" hop Fully specified path For example, if you want to let R9 go to R2 via R1-R3-R4 strictly, then use “hops=10.1.9.9:strict,10.1.9.1:strict,10.1.3.1:strict,10.1.3.3:strict,10.3.4.3: strict,10.3.4.4:strict,10.2.4.4:strict,10.2.4.2:strict” Loose – There are acceptable other hops between previous hop and defined hop Not fully specified path For example, if you want to let R9 go to R2 via R4, you don’t care which routers it will go through, then you can use “hops=10.1.1.4:loose” 69 MTCINE Bootcamp + IPv6 Workshop CONFIGURING TE Enable MPLS TE feature in OSPF for your backbone area. [admin@R9] /routing ospf> set 0 mpls-te-area=backbone mpls-te-router-id=lo0 Configure RSVP bandwidth on all MPLS enabled interface. [admin@R9] /mpls traffic-eng interface> add interface=ether1 bandwidth=50M add interface=ether2 bandwidth=50M Create path option with static path. [admin@R9] /mpls traffic-eng tunnel-path> add name=PATH-R9-R2 use-cspf=no hops=10.1.9.9:strict,10.1.9.1:strict, 10.1.3.1:strict,10.1.3.3:strict,10.3.4.3:strict,10.3.4.4:strict, 10.2.4.4:strict,10.2.4.3:strict Create TE Tunnel interface. Use “PATH-R9-R2” as Primary Path Request 10Mbps bandwidth from 10.1.1.9 to 10.1.1.2 [admin@R9] /interface traffic-eng interface> add name=TE-R9-R2 \ bandwidth=10M primary-path=PATH-R9-R2 \ from-address=10.1.1.9 to-address=10.1.1.2 MONITORING TE Monitor TE tunnel status. [admin@R9] /interface traffic-eng> monitor 0 Monitor VPLS transport status. [admin@R9] /interface vpls> monitor 0 TE tunnel PATH and RESV state. [admin@R9] /mpls traffic-eng path-state> print [admin@R9] /mpls traffic-eng resv-state> print [admin@R9] /mpls traffic-eng interface> print 70 MTCINE Bootcamp + IPv6 Workshop LAB: STATIC PATH TE LAB: STATIC PATH TE (CONT.) This lab is based on “LDP Based VPLS” full scale lab topology. The purpose of this lab is to implement following policies using MPLS Traffic Engineering: Traffic from R1 to R2 must travel through R3 and R4 Traffic from R4 to R3 must travel through R2, R9, and R1 Enable RSVP on all OSPF interfaces of backbone router. Enable MPLS TE support for OSPF Area 0. Configure TE tunnel on R1 and R4 using static path option. Send traffic between PCs, and monitor traffic pattern. Test Internet connectivity. 71 MTCINE Bootcamp + IPv6 Workshop SECONDARY TE TUNNEL PATH TE does not switch paths automatically to secondary, tunnel must be re-optimized: Manually by “optimize” command Automatically at configured “reoptimize-interval” TE tries to switch back to primary every minute. Can be changed by “primary-retry-interval” Switching paths may take some time, depends on: OSPF timeouts, routing table updates, TE timeout settings. RouterOS does not support MPLS Fast Reroute. AUTO BANDWIDTH By default TE tunnels do not apply rate limitations, “bandwidth” settings are only for reservation accounting To make tunnels more flexible two features were added: “bandwidth-limit” – Hard rate limit allowed to enter the tunnel, limit is percent of tunnel bandwidth. Auto bandwidth adjustment – measures average rate during “auto-bandwidth-avg-interval”, tunnel keeps highest average rate seen during “auto-bandwidth-update-interval”. When update interval expires, tunnel chooses new highest rate from “auto-bandwidth-range”. Both options can be used in combination. 72 MTCINE Bootcamp + IPv6 Workshop LAB: TE WITH BACKUP PATH AND BANDWIDTH LIMIT LAB: TE WITH BACKUP PATH AND BANDWIDTH LIMIT (CONT.) This lab is based on “LDP Based VPLS” full scale lab topology. The purpose of this lab is to implement following policies using MPLS Traffic Engineering: Traffic from R1 to R2 must travel through R3 and R4 When primary path failed, use R9 as backup path TE’s initial bandwidth reservation is 10Mbps Allow this TE tunnel to automatically adjust bandwidth reservation between 5Mbps and 50Mbps, with 20% increment per update Do the same configuration for RSVP and OSPF as previous lab. Configure TE tunnel on R1 with backup path. Send traffic between PCs, monitor bandwidth reservation changes, and monitor link fail-over events. 73 MTCINE Bootcamp + IPv6 Workshop QUESTIONS & ANSWERS If you have any questions, feel free to ask! Or you would like to review a specific topic, please request. MTCINE EXAM This is an open book exam, you ARE ALLOWED to read the book, use search engine, or login to the router. YOU ARE NOT ALLOWED to print screen, record, capture, copy, save, disclose, or share any exam question! DO NOT talk to other participants during the exam! If you face any technical problem on exam portal, please RAISE YOUR HAND and talk to the trainer or training assistant. If you are going to do testing on your router, make sure you are not accessing to exam portal via it. Good luck in your exam! 74 MTCINE Bootcamp + IPv6 Workshop INTRODUCTION TO IPV6 IPv6 Packet Format IPv6 Addressing IPv6 Subnetting IPv6 Protocols INTRODUCTION TO IPV6 New version of Internet Protocol version 6 which can support 2128 bits – 340 decillion IPv6 addresses. IPng protocol was initially developed in 1994 for solving the issue of IPv4 addresses exhaustion. IPv6 was also called IPng in the early days of IPv6 protocol development stage. IPv6 deployment started in 1999. It is expressed in hexadecimal digits as shown as below 2001:0db8:0582:ae33::29 75 MTCINE Bootcamp + IPv6 Workshop IPV4 AND IPV6 HEADER COMPARISON IPV4 VS. IPV6 IPv4 IPv6 Address Space 32-bit 128-bit Possible Addresses 232 2128 Address Format 192.0.2.1 2001:db8:3:4:5:6:7:8 Header Length 20 bytes 40 bytes Header Fields 14 8 IPsec Optional Should 76 MTCINE Bootcamp + IPv6 Workshop IPV6 HEADER Version = 4-bit value set to 6. Traffic Class = 8-bit value. Flow Label = 20-bit value. Payload Length = 16-bit value. Replaces IPv4 TOS field The size of the rest of the IPv6 packet following the header – replaces IPv4 Total Length Next Header = 8-bit value. Replaces IPv4 Protocol, and indicates type of next header Hop Limit = 8-bit value. Source address = 128-bit value. Destination address = 128-bit value. Decreased by one every IPv6 hop (IPv4 TTL counter) HEADER FORMAT – EXTENSION HEADERS All optional fields go into extension headers. These are daisy chained behind the main header. The last 'extension' header is usually the ICMP, TCP or UDP header Makes it simple to add new features in IPv6 protocol without major re-engineering of devices. Number of extension headers is not fixed / limited. 77 MTCINE Bootcamp + IPv6 Workshop HEADER FORMAT – COMMON HEADERS Common values of Next Header field: 0 Hop-by-hop option (extension) 2 ICMP (payload) 6 TCP (payload) 17 UDP (payload) 43 Source routing (extension) 44 Fragmentation (extension) 50 Encrypted security payload (extension, IPSec) 51 Authentication (extension, IPSec) 59 Null (No next header) 60 Destination option (extension) HEADER FORMAT – ORDERING OF HEADERS Order is important because: Hop-by-hop header has to be processed by every intermediate node Routing header needs to be processed by intermediate routers At the destination fragmentation has to be processed before other headers This makes header processing easier to implement in hardware. 78 MTCINE Bootcamp + IPv6 Workshop PATH MTU AND PATH MTU DISCOVERY Path MTU: Path MTU (PMTU) is the largest packet size that can traverse between a source and destination without fragmentation IPv6 requires MTU 1280 bytes or greater IPv4 requires MTU 68 bytes Path MTU Discovery: determining the path MTU between two IP hosts To discover and take advantage of PMTU greater than 1280, it is strongly recommended to implement PMTU discovery For packets that are larger than PMTU fragmentation is used. IPV6 ADDRESS SPACE IPv4: 32 bits = 4,294,967,296 possible addressable devices IPv6: 128 bits: 4 times the size in bits =340,282,366,920,938,463,463,374,607,431,768,211,456 nodes 79 MTCINE Bootcamp + IPv6 Workshop IPV6 ADDRESSING REPRESENTATION 16-bit fields in case insensitive colon hexadecimal representation. Leading zeros in a field are optional, can be omitted. 2031:0000:130F:0000:0000:09C0:876A:130B 2031:0:130F:0:0:9C0:876A:130B Successive fields of 0 represented as ::, but only once in an address. 2031:0:130F::9C0:876A:130B IPv4-compatible address representation. Loopback address representation. Unspecified address representation. 0:0:0:0:0:0:192.168.30.1 => ::192.168.30.1 =>:: C0A8:1E01 0:0:0:0:0:0:0:1=> ::1 0:0:0:0:0:0:0:0=>:: EXERCISE 2001:0db8:0000:0000:0000:0000:0000:0000 2001:0db8:0000:0000:d170:0000:1000:0ba8 2001:0db8:00a0:0000:0000:00f6:0000:00aa 2001:0db8:0fc5:007b:ab70:0210:0000:00bb 80 MTCINE Bootcamp + IPv6 Workshop IPV6 ADDRESSING Generally there are three address types: Unicast : One to One (Global, Unique Local, Link local) Anycast : One to Nearest (Allocated from Unicast) Multicast : One to Many There is no broadcast in IPv6. A single interface may be assigned multiple IPv6 addresses of any type (unicast, anycast, multicast). IPV6 ADDRESSING (CONT.) 81 MTCINE Bootcamp + IPv6 Workshop IPV6 ADDRESS ALLOCATION The allocation process is: The IANA is allocating out of 2000::/3 for initial IPv6 unicast use Each registry gets a /12 prefix from the IANA Registry allocates a /32 prefix (or larger) to an IPv6 ISP Policy is that an ISP allocates a /48 prefix to each end-customer INTERFACE ID Lowest order 64-bit field of unicast address may be assigned in several different ways: Auto-configured from a 64-bit EUI-64, or expanded from a 48-bit MAC address (e.g., Ethernet address) Auto-generated pseudo-random number (to address privacy concerns) Assigned via DHCP Manually configured 82 MTCINE Bootcamp + IPv6 Workshop EUI-64 EUI-64 address is formed by inserting FFFE between the company-id and the manufacturer extension, and setting the “u” bit to indicate scope. Global scope: for IEEE 48-bit MAC Local scope: when no IEEE 48-bit MAC is available (eg serials, tunnels) UNIQUE-LOCAL Unique-Local addresses used for: Local communications & inter-site VPNs Local devices such as printers, telephones, etc Site Network Management systems connectivity Not routable on the Internet 83 MTCINE Bootcamp + IPv6 Workshop LINK-LOCAL Link-Local addresses used for: Automatically assigned by Router as soon as IPv6 is enabled. Communication between two IPv6 device (like ARP but at Layer 3) Next-Hop calculation in Routing Protocols Mandatory Address Only link specific scope. Remaining 54 bits could be Zero or any manual configured value. MULTICAST USE Broadcasts in IPv4: Interrupts all devices on the LAN even if the intent of the request was for a subset Can completely swamp the network (“broadcast storm”) Broadcasts in IPv6 are not used and replaced by multicast. Multicast: Enables the efficient use of the network Multicast address range is much larger 84 MTCINE Bootcamp + IPv6 Workshop IPV6 MULTICAST ADDRESS IP multicast address has a prefix FF00::/8 The second octet defines the lifetime and scope of the multicast address. IPV6 MULTICAST ADDRESS EXAMPLES All nodes (on link) : FF02::1 All routers (on link) : FF02::2 RIPng: The multicast address All RIP Routers is FF02::9 Note that 02 means that this is a permanent address and has link scope OSPFv3: The multicast address All OSPF Routers is FF02::5 The multicast address All DR Routers is FF02::6 85 MTCINE Bootcamp + IPv6 Workshop ANYCAST ADDRESS Multiple hosts can have the same anycast address. Send to any one member of this group (usually the nearest). Indistinguishable from a unicast address. Use cases: load balancing, content delivery networks (CDN). When using anycast address, Duplicate Address Detection has to be disabled for that IP. SUBNETTING Network Engineer needs to know the solid understanding how to subnet the network for efficiently using the IPv6 addresses. IPv6 Subnetting is similar concept with IPv4 subnetting. One Hex Digit = 4 bits : 0x4 = 0100 0x6 = 0110 0xA = 1010 86 MTCINE Bootcamp + IPv6 Workshop SUBNETTING EXAMPLE Provider A has been allocated an IPv6 block: 2001:0DB8::/32 Prefix-length is defined the same as CIDR value in IPv4. Provider A will delegate /48 blocks to its customers. Find the blocks provided to the first 4 customers. Original Block : 2001:0DB8::/32. Rewrite as /48 Block: 2001:0DB8:0000:/48. SUBNETTING EXAMPLE 2001:0DB8:0000::/48 In bits 2001:DB8: 0000 0000 0000 0000 2001:DB8:0000::/48 2001:DB8: 0000 0000 0000 0001 2001:DB8:0001::/48 2001:DB8: 0000 0000 0000 0010 2001:DB8:0002::/48 2001:DB8: 0000 0000 0000 0011 2001:DB8:0003::/48 87 MTCINE Bootcamp + IPv6 Workshop EXERCISE I (IPV6 SUBNETTING) Identify the first four /36 address blocks out of 2001:DB8::/32. 1.-----------------------------2.-----------------------------3.-----------------------------4.------------------------------ EXERCISE II (IPV6 SUBNETTING) Identify the first six /37 address blocks out of 2400:ABCD::/32. 1.-----------------------------2.-----------------------------3.-----------------------------4.-----------------------------5.-----------------------------6.------------------------------ 88 MTCINE Bootcamp + IPv6 Workshop NEIGHBOR DISCOVER PROTOCOL Replaces ARP on IPv4. Tracks and discovers other IPv6 hosts. Auto-configures address. Uses ICMPv6 protocol. Has 5 message types: Router solicitation (type 133) Router advertisement (type 134) Neighbor solicitation (type 135) Neighbor advertisement (type 136) Redirect (type 137) NEIGHBOR DISCOVER PROTOCOL Router Discovery DAD (Duplicate Address Detection) Each IPv6 host will wait to use its address unless it knows that no other device is using the same address MAC Address Discovery NDP is used to learn about all available IPv6 routers in the subnet Once a host has done the DAD check and is using an IPv6 address, it will have to discover the MAC addresses of hosts it wants to communicate with SLAAC (Stateless Address Auto-configuration) We’ll cover SLAAC in next slide, but NDP is used to learn what address and prefix length the host should use 89 MTCINE Bootcamp + IPv6 Workshop NS AND NA MESSAGE It is used to look for MAC Link Layer address as replacement of ARP. It can be used for DAD (Duplicate Address Detection) ADDRESS CONFIGURATION Auto configuration of link local address Stateless address auto-configuration (SLAAC) Additional options with DHCPv6 Stateful Stateless DHCPv6 Static Manually assign the IPv6 address on the interface 90 MTCINE Bootcamp + IPv6 Workshop STATELESS AUTO-CONFIGURATION PC sends router solicitation (RS) message Router responds with router advertisement (RA) This includes prefix and default route RFC6106 adds DNS server option PC configures its IPv6 address by concatenating prefix received with its EUI-64 address DHCPV6 DHCP for IPv6 is called DHCPv6 and comes in two forms: Stateless Stateful A stateless DHCPv6 server doesn’t keep track of anything for clients. When you use SLAAC, you still need stateless DHCPv6 to learn about the DNS servers. Stateful DHCPv6 works similar with DHCP for IPv4. It provides IP information (IP addresses, Prefix Length, Default Gateway, DNS Servers, and other DHCP options) to clients. DHCPv6 uses a Solicit, Advertise, Request and Reply message. 91 MTCINE Bootcamp + IPv6 Workshop STATELESS DHCPV6 If necessary additional configuration can be obtained (for example static routes) It is done by DHCPv6. To configure open IPv6 → ND Configure: Required interfaces and Enable “Other Configuration” STATELESS DHCPV6 (CONT.) Add new DHCP Server on Interface 92 MTCINE Bootcamp + IPv6 Workshop STATELESS DHCPV6 (CONT.) Note: For MS Windows clients it is necessary to configure DHCPv6 in order to obtain DNS configuration. Make sure, that IPv6 DNS server is configured in IP → DNS. DNS OVERVIEW DNS maps one resource to another resource: IP address to hostname (and vice versa) Useful for long addresses (such as IPv6) Globally distributed, hierarchical tree structure. Three components: namespace, resolvers, servers. Resource records are the actual mappings: RR Types: A, AAAA, PTR, CNAME, etc 93 MTCINE Bootcamp + IPv6 Workshop HOW DNS WORKS LAB: IPV6 CONNECTIVITY TEST This lab needs two people in the group. It is just for testing directly connected link. Assign the IP address on the link as shown in figure. Your PC will be connected with ether2 of router and will receive the prefix length that the router advertised by using SLAAC. Ping to gateway IP from PC. Ping router to router . 94 MTCINE Bootcamp + IPv6 Workshop IPV6 STATIC ROUTING For supporting IPv6, RouterOS must have IPv6 package. Link-local addresses are configured as gateways if the interface is specified. Administrative Distances are same as IPv4. For dropping traffic in routing table, there is no “blackhole” and “prohibit” route types, there is only “unreachable”. Command Line: /ipv6 route add dst-address=2002::/16 gateway=fe80::21a:4dff:fe56:1f4d%ether1 [admin@MikroTik] > /ipv6 route print detail Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r - rip, o - ospf, b - bgp, U - unreachable ... 1 A S dst-address=2002::/16 gateway=fe80::21a:4dff:fe56:1f4d%ether1 reachable distance=1 scope=30 target-scope=10 LAB : IPV6 STATIC ROUTING This lab needs two people in a group. Configure static route on R1 to reach 2001:DF1:C700:A002::/64 via R2. Configure static route on R2 to reach 2001:DF1:C700:A001::/64 via R1. You should be able to ping between two PCs. 95 MTCINE Bootcamp + IPv6 Workshop IPV6 TRANSITION TECHNOLOGIES Dual-Stack 6to4 & 6in4 6RD DS-Lite Teredo TRANSITION TECHNOLOGIES Currently we are still using IPv4 networks. We do need the transition technologies to let IPv6 compatibly work with IPv4. There are some transition technologies we would like to explain here: Dual-Stack 6to4 & 6in4 6RD Teredo DS-Lite 96 MTCINE Bootcamp + IPv6 Workshop DUAL-STACK Parallel Usage of IPv4 and IPv6 on a host. Hosts and routers are able to communicate either protocol. The most recommended way of implementing IPv6. Most operating systems now preferred IPv6 over IPv4 while both protocols are available on the host. 6TO4 TUNNEL Allows isolated IPv6 domains to be connected over an IPv4-only network. Can be point-to-multipoint. IPv6 packets are encapsulated in IPv4 packets. Using IP Protocol 41 20 bytes encapsulation overhead Allocated Prefix 2002::/16 Two key components: 6to4 relay (anycast address 192.88.99.1) 6to4 client 97 MTCINE Bootcamp + IPv6 Workshop 6TO4 OPERATIONS Client connects to the nearest Relay from its routing prospective. Each client is automatically assigned a /48 by embedding its public IPv4 address into 2002::/16 prefix: For example, client with IPv4 address 103.97.110.10 is connecting to a 6to4 relay, its IPv6 prefix will be: 2002:<client-public-ipv4>::/48 Convert 103.97.110.10 to Hexadecimal 67 61 6E 0A Embed 67 61 6E 0A into 2002::/16 2002:6761:6E0A::/48 Client points default gateway to 6to4 relay for getting internet access. 6TO4 EXAMPLE 6to4 Network Design Sample 2002:<router-ip-address-in-hex>::/48 Create Tunnel between two IPv6 Network over IPv4 only network. 98 MTCINE Bootcamp + IPv6 Workshop 6IN4 In contrast with 6to4, 6in4 requires manual configuration, but it uses the same encapsulation (IP Protocol 41). Two key components: IPv6 Tunnel Broker Server IPv6 Tunnel Broker Client Works similar to EoIP/GRE, tunnel has to be configured manually on both peers (server and client) Static addressing. No allocated prefix 2002::/16 Client’s IPv6 prefix have to be assigned manually IPv6 prefix is independent from its public IPv4 IPv6 prefix won’t change when IPv4 endpoint changes LAB: IPV6 TUNNEL BROKER 99 MTCINE Bootcamp + IPv6 Workshop LAB: IPV6 TUNNEL BROKER (CONT.) This lab is based on previous “Route Reflector” full scale lab topology. The purpose of this lab is to allow the users to have access to other IPv6 networks and IPv6 Internet via an IPv4-only network. Restore your “Route Reflector” full scale lab backup. Configure additional IPv4/IPv6 addresses as necessary according to the diagram. Add a CPE router between your PC and ISP. Configure your PC to use the CPE router as default gateway. Configure IPv6 DNS manually on PCs using Windows. LAB: IPV6 TUNNEL BROKER (CONT.) R9 is Tunnel Broker Server. R1, R2, R3, R4 are Tunnel Broker Clients. Create a 6to4 tunnel between each TB Client to TB Server. Tasks on TB Server (R9): Tasks on TB Clients (Other routers): Assign IPv6 point-to-point address to each 6to4 tunnel Route a /56 User LAN prefix to each user’s 6to4 tunnel Configure IPv6 point-to-point address Point default gateway to TB Server Configure LAN using the first /64 of the routed /56 prefix Test connectivity from your PC to IPv6-enabled websites. 100 MTCINE Bootcamp + IPv6 Workshop 6RD IPv6 Rapid Deployment is 6to4 derivative. IPv6 relay is controlled by your ISP. From client to ISP is IPv4 network only. On the client side additional software is needed to encapsulate IPv6 into IPv4 packets. DS-LITE Stands for Dual-Stack Lite. IPv6-only links are used between the ISP and the client. Client has native IPv6 connectivity. When and IPv4 packet needs to be sent, it is encapsulated into an IPv6 packet. Sent to the ISP’s NAT box which decapsulates and forwards it as IPv4 traffic. 101 MTCINE Bootcamp + IPv6 Workshop DS-LITE (CONT.) NAT is centralized at ISP-level. Clients use private IPv4 addresses. e.g. 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 ISP → Client network is IPv6 only. TEREDO Teredo encapsulates IPv6 traffic into IPv4 UDP packets. The traffic is sent through IPv4 Internet. Unlike 6to4, Teredo works behind an IPv4 NAT. Uses Teredo prefix 2001::/32. Can only provide a single IPv6 address per tunnel endpoint. Cannot be used to distribute addresses to multiple hosts like 6to4. Developed by Microsoft. Described in RFC4380. 102 MTCINE Bootcamp + IPv6 Workshop ISP IPV6 ROUTING Open Shortest Path First version 3 (OSPFv3) MP-BGP IPv6 Address Family Dual-Stack ISP network deployment IPV6 ROUTING IPv6 routing works similar to IPv4. Static and dynamic routing can be used. IPv6 dynamic routing protocols: RIP next generation (RIPng) OSPF version 3 (OSPFv3) MP-BGP IPv6 Address Family IPv6 link-local addresses can be used to communicate between hosts in the same broadcast domain. Link-local automatically appears on every IPv6 link Fully functional internal IPv6 network can be created with link-local addresses 103 MTCINE Bootcamp + IPv6 Workshop OPEN SHORTEST PATH FIRST VERSION 3 (OSPFV3) RouterOS supports OSPFv3 for IPv6. There are some similarities and some differences between OSPFv2 and OSPFv3 as shown below. Similarities: Packet Type Interface Type Neighbor Discovery Pattern LSA flooding & aging Administrative Distance Cost…etc. Differences are explained in next slide. OSPFV2 VS. OSPFV3 Function OSPFv2 OSPFv3 Routed Protocol Support IPv4 IPv6 IPv4 (Not implemented in ROS) OSPF All Routers Multicast 224.0.0.5 FF02::5 OSPF DR and BDR Multicast 224.0.0.6 FF02::6 Supports Multiple OSPF instances per interface No Yes Authentication Plain text or MD5 IPSec Authentication (Not implemented in ROS) Header Size 24 bytes 16 bytes LSA Types 7 9 (LSA 8, LSA 9) Interface ID IPv4 address Link-local address Running OSPF Add OSPF network Add OSPF interface 104 MTCINE Bootcamp + IPv6 Workshop OSPFV2 LSA VS. OSPFV3 LSA OSPFv2 Type 1 and Type 2 LSAs are used for topology and network information. A single LSA contains information about the topology and the networks that are used OSPFv3 No Prefix information in Type 1 and Type 2 Link-local addresses to be used for next hops – Type 8 LSA Prefixes – Type 9 LSA MP-BGP IPV6 ADDRESS FAMILY Multiprotocol BGP (MP-BGP) is supported in RouterOS. There are two deployment options for advertising IPv6 prefixes in BGP. 1. 2. Turn on IPv6 Address Family over IPv4 BGP session Initiate another separate IPv6 BGP session with IPv6 Address Family We are going to configure the 2nd option in our upcoming “Dual-Stack ISP Network” lab. 105 MTCINE Bootcamp + IPv6 Workshop LAB: DUAL-STACK ISP NETWORK LAB: DUAL-STACK ISP NETWORK (CONT.) This lab is based on previous “Route Reflector” full scale lab topology. The purpose of lab is to enable IPv6 in the ISP network for offering Dual-Stack connectivity to customers. Restore your “Route Reflector” full scale lab backup. Configure additional IPv4/IPv6 addresses as necessary according to the diagram. Add a CPE router between your PC and ISP. Configure your PC to use the CPE router as default gateway. Configure IPv6 DNS manually on PCs using Windows. 106 MTCINE Bootcamp + IPv6 Workshop LAB: DUAL-STACK ISP NETWORK (CONT.) Run OSPFv3 between ISP backbone routers. Configure new iBGP sessions using IPv6 Loopbacks. R3 and R4 are Route Reflectors R1, R2, R9 are Route Reflector Clients Set “next-hop-self” Advertise customer prefixes into iBGP. The same as what you did with IPv4 OSPF ISP-to-Customer link 2001:df1:c700:b64R::/64 Customer LANs 2001:df1:c700:cR00::/56 CPE routers point default gateway to ISP routers. ISP routers route Customer LAN prefix to CPEs. Test IPv6 connectivity between customers and IPv6 Internet. LAB: DUAL-STACK ISP NETWORK – RECURSIVE LOOKUP FAILED After you have configured the routers as described in previous slide, you would realize… IT DOES NOT WORK!! But don’t be afraid, this is normal behavior in current version of RouterOS: Recursive next hop look up between dynamic routing protocols is broken BGP route FAILS to lookup its next hop with OSPF/RIP routes BGP route CAN lookup its next hop with static routes This is a bug! 107 MTCINE Bootcamp + IPv6 Workshop LAB: DUAL-STACK ISP NETWORK – WORKAROUND So what can we do? Workaround: 1. 2. Manually configure static routes to all backbone router’s Loopbacks, for BGP to look up Implement routing filter, manually set all BGP next hops to be appropriate IPv6 point-to-point address or link-local address Yes, you will lose the capabilities of fail-over and re-routing when links are down. Eventually, this has to be fixed by MikroTik, in later version of RouterOS. QUESTIONS & ANSWERS If you have any questions, feel free to ask! Or you would like to review a specific topic, please request. 108 MTCINE Bootcamp + IPv6 Workshop THE END THANKS FOR YOUR ATTENTION! Contact Me [email protected] 109
