MTCINE WIZMASTER 20171103-20171108IPV6 Book PDF

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 CCIE # 47682
 Billing solutions for service providers
 ISP core network design and operations
 Certifications:
 Areas of interest: BGP, MPLS, IPv6
1
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
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
MIKROTIK CERTIFICATIONS (CONT.)

 MTCNA
 Fundamental and overall knowledge about RouterOS
 First level of MikroTik certification
 MTCRE
 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

 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

 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
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  Day 4
 Border Gateway Protocol  MPLS Layer 3 VPN
(BGP)  MPLS Layer 2 VPN
 Day 2  Day 5
 Border Gateway Protocol  Traffic Engineering (TE)
(BGP) (Cont.)  Certification Exam
 Day 3  Day 6
 Service Provider BGP Design  IPv6 workshop
 Multiprotocol Label
Switching (MPLS)
6
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
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
AUTONOMOUS SYSTEM NUMBER (ASN)

 Two ranges
 0-65535 (original 16-bit range)
 65536-4294967295 (32-bit range – RFC4893)
 Usage:
 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
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.
Add AS100 to the path
10.1.0.0/24 AS Path: 100
AS100
AS200
Reject, AS100
already in the path

AS Path: 200,100
AS Path: 300,200,100
AS300
 AS300 receives 10.1.0.0/24 from AS200, AS Path: 200,100.
10
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
PACKET FORMAT
 Uses TLVs (Type-Length-Value):
 Marker (128-bit)
 For authentication
 Length (16-bit)
 Type (8-bit)
 Value
 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
BGP SESSION & UPDATES

Open with ASN4 capability
AS100 AS200
Notification unsupported cap.
Passive
Open without capability BGP peer
Keepalive
AS100 AS200
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 REMOTE-AS
0 E default 10.10.10.1 3000
13
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 AS300
AS100 R3
R1
R4
R5
iBGP
R6
eBGP
AS400
14
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

AS100 AS200
172.16.1.1/24 172.16.1.2/24
eth1 eth1
R1 R2 10.88.0.0/24
 Configure your routers according to the topology.

 Do eBGP peering on connected interface.
[admin@R1] /routing bgp instance> set default as=100
[admin@R1] /routing bgp peer> add remote-address=172.16.1.2 remote-as=200
[admin@R2] /routing bgp instance> set default as=200
 Advertise prefix 10.88.0.0/24 on R2.

[admin@R2] /routing bgp network> add network=10.88.0.0/24
15
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
LAB: IBGP PEERING

lo0: 10.1.1.1 lo0: 10.1.1.2
AS100
172.16.1.1/24 172.16.1.2/24
eth1 eth1 R2 10.88.0.0/24
R1

 Point static route or enable IGP between R1 and R2:
[admin@R1] /ip route> add dst-address=10.1.1.2 gateway=172.16.1.2
[admin@R2] /ip route> add dst-address=10.1.1.1 gateway=172.16.1.1
# OR
[admin@R1] /routing ospf network> add network=172.16.1.0/24 area=backbone
[admin@R1] /routing ospf network> add network=10.1.1.1 area=backbone
[admin@R2] /routing ospf network> add network=172.16.1.0/24 area=backbone
[admin@R2] /routing ospf network> add 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
remote-as=100 update-source=lo0
LAB: EBGP MULTI-HOP WITH LOOPBACKS

lo0: 10.1.1.1 lo0: 10.1.1.2
AS100 172.16.1.1/24 172.16.1.2/24 AS200

eth1 eth1
R1 R2 10.88.0.0/24
eth2 eth2
172.16.2.1/24 172.16.2.2/24

 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:

remote-as=200 multihop=yes update-source=lo0
remote-as=100 multihop=yes update-source=lo0
17
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. Nexthop must be reachable.
2. Highest Weight (default 0).
3. Highest Local Pref. (default 100).
4. Shortest AS Path.
5. Locally originated path (aggregated route or BGP network).
6. Lowest origin type (IGP < EGP < Incomplete).
7. Lowest MED (default 0).
8. Prefer eBGP over iBGP.
9. Lowest Router ID.
10. Lowest Originator ID.
11. Shortest route reflection cluster (default 0).
12. Lowest neighbor address.
18
BGP PATH ATTRIBUTES

 There are four categories of path attribute:
 Well-known mandatory
 This attribute MUST exist in the BGP UPDATE. If this attribute is missing a
NOTIFICATION error is generated and the session is closed
 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
 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
BGP PATH ATTRIBUTES (CONT.)

Type Code (Decimal) Attribute Name Category
1 ORIGIN 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.
172.16.0.0/24
AS100 Nexthop: 10.1.1.1
172.16.0.0/24
172.16.0.0/24 R1 10.1.1.1/30 Nexthop: 10.1.1.1
R3
10.1.1.2/30 R2
lo0: 10.30.1.2
lo0: 10.30.1.1
AS200
20
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).
172.16.0.0/24
AS100 Nexthop: 10.1.1.1
172.16.0.0/24
172.16.0.0/24 R1 10.1.1.1/30 Nexthop: 10.30.1.1
R3
10.1.1.2/30 R2
lo0: 10.30.1.2
lo0: 10.30.1.1
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 R2 10.1.1.0/24
Weight: 100 Weight: 50
Best Path
AS300
21
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.
 Path with higher 10.1.1.0/24
AS100 AS200
Local Pref. is
preferred R1 R5
(default: 100).
AS300
10.1.1.0/24
Local Pref.: 200 R2 R4
Best Path 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 AS200
R2
R3
10.1.1.0/24
10.1.1.0/24 10.1.1.0/24
AS Path:200,100 AS Path:100 AS100
AS400 R1
R4
10.1.1.0/24
AS Path: 300,200,100
 Can be manipulated for traffic engineering.

 AS Path Prepending in outbound filter
22
ORIGIN
 Information about how the prefix is originated into BGP.
 Prefers IGP over EGP, and EGP over Incomplete.
 IGP
 Interior Gateway Protocol
 Prefix is fed into BGP by the network command
 EGP
 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
MED (CONT.)
10.1.1.0/24
AS100 10.1.1.0/24 AS300
MED: 10 MED not advertised
R1 R4
10.1.1.0/24
MED: 50
10.1.1.0/24 10.1.1.0/24
No MED MED: 100
R2 R3
10.1.1.0/24
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
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: AS200
10.100.0.0/22 Unreachable ether1 ether1
10.100.0.0/24 Unreachable 172.16.1.1/24 172.16.1.2/24 Redistribute
R1 R2
10.100.1.0/24 Unreachable Connected
10.100.2.0/24 Unreachable
Redistribute Static

 Do eBGP peering between AS100 and AS200.
 Redistribute static on R1.
 Redistribute connected on R2.

[admin@R1] /routing bgp instance> set default as=100 redistribute-static=yes
[admin@R2] /routing bgp instance> set default as=200 redistribute-connected=yes
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
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
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
R1 R2
Redistribute Static
 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-OUT prefix=10.100.1.0/24 action=accept
add chain=EBGP-AS200-IPV4-OUT action=discard
26
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
R1 R2
Redistribute Static
 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-OUT bgp-as-path=“^\$” action=accept
add chain=EBGP-AS100-IPV4-OUT action=discard
27
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 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
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
 iBGP with R3
 eBGP with R9, use “set-bgp-prepend=3” in outbound filter
 R2
 iBGP with R4
 eBGP with R9, use “set-bgp-prepend=3” in outbound filter
 R3
 iBGP with R1
 eBGP with R4
 R4
 iBGP with R2
 eBGP with R3
 R9
 eBGP with R1 and R2
 Traceroute from AS99 to AS100 and AS200 for verification.
29
PREFIX AGGREGATION
 Summarization of more specific routes into supernet.
 Can be used to hide topology.
 Works only on the same instance BGP routes. AS100
R1
AS400 10.1.1.0/24
10.0.0.0/8
R4 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
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
R1 R3 R1 R3
R2 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
LAB: ROUTE REFLECTOR
1. Configure iBGP full mesh and advertise all customer LANs

into iBGP, then test connectivity between LANs.
2. 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
CONFEDERATION SETUP
AS200
AS Path: 100,300 R9 AS300
R8
R3 R4
AS20
R1
AS Path: (20,30)
AS10 R5 R6
R2
AS30
AS400 AS100
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.

Single-homed
ISP 0.0.0.0/0 Customer
172.16.0.0/16
Global Internet AS65500
172.16.0.0/24
AS300
33
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
ISP Customer
172.16.0.0/16
Global Internet AS65500
172.16.0.0/24
AS300
PRIVATE AS REMOVAL
Global Internet
AS65500
ISP 172.16.0.0/24
172.16.0.0/16
 Private AS cannot be AS65501

leaked to public 172.16.1.0/24
AS300
 Available for eBGP
neighbors
AS65502
 Announce only
172.16.2.0/24
aggregate route
 Use following command:
/routing bgp peer set <peer-name> remove-private-as=yes
34
MULTI-HOMED
 Needs to request own IP/ASN from:
 Upstream ISP
 Local Internet Registry (LIR)
 JPNIC, CNNIC, SGNIC…etc. Global Internet
 Regional Internet Registry (RIR)
 APNIC, ARIN, RIPE NCC…etc.
 Typically receive full route AS200
AS100
from upstream ISPs.
R3
 Advertise own address R1
space to upstream ISPs.
 Supports independent routing policies. R2
 Use BGP to do load sharing or fail-over. 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
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
 provide information about origin of the route, such as: location, network
name, relationship (customer, peer, upstream), sent by upstream provider
 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
 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
BGP COMMUNITY – EXAMPLE 1

 Assume that you don't want AS200 (R2) to propagate
routes learned from AS100 (R1).
10.1.1.0/24
AS300 AS100
R1
R3 AS200
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 AS 400

10.2.2.0/24 community=100:501
ISP
AS100
AS300 AS 500
37
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:
 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
 To downstream customers:
 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
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
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
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
MPLS egress LER
Backbone
MPLS BASICS (CONT.)

 Also called 2.5 layer protocol.
 Shim header (32-bit) placed between OSI Layer 2 and Layer 3.
 After Layer 2 header and before Layer 3 header
 Multiple labels can be used for MPLS packet encapsulation
 Creation of a label stack
 MPLS Label format:
L2 MPLS L3
 Label (20 bits)
 EXP (3 bits)
 For QoS enforcement
Label EXP S TTL
 End of stack flag (1 bit)
 Whether current label is the last in the stack
 TTL (8 bits)
41
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 set dynamic-label-range=1000-1048575
/mpls local-bindings
/mpls remote-bindings
/mpls forwarding-table
42
STATIC LABEL MAPPING – EXAMPLE

lo0:1.1.1.1 lo0:2.2.2.2 lo0:3.3.3.3
R1 R2 R3
Local: DST LABEL DST LABEL DST LABEL

1.1.1.1 impl-null 1.1.1.1 21 1.1.1.1 21
2.2.2.2 22 2.2.2.2 impl-null 2.2.2.2 22
3.3.3.3 23 3.3.3.3 23 3.3.3.3 impl-null
DST HOP LABEL DST HOP LABEL DST HOP LABEL
Remote: 2.2.2.2 R2 impl-null 1.1.1.1 R1 impl-null 2.2.2.2 R2 impl-null
3.3.3.3 R2 23 3.3.3.3 R3 impl-null 1.1.1.1 R2 21
IN OUT DST IN OUT DST IN OUT DST
Fwd: 22 2.2.2.2 21 1.1.1.1 21 21 1.1.1.1
23 23 3.3.3.3 23 3.3.3.3 22 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

nexthop=10.3.4.3 label=301

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
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 10.1.1.0/24
10.1.1.0/24 Label 21 Label 22 Label 23
Local binding Local binding Local binding

Label 21 Label 22 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
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.

 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 Label1
Path 1 Path 1 Path 1
Path 1
Path 2
Label1 Label1
Path 2 Path 1
45
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
PENULTIMATE HOP POPPING (PHP)

(CONT.)
PHP
Implicit NULL
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
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
 Configure in “/mpls ldp advertise-filter”
 Which bindings should be accepted
 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
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 Label: 23 Label: 34
R1 R2 R3 R4
Label: 32 Label: 43
49
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
MPLS L3VPN (CONT.)

VPN A
Site 1 RR
CE CE
VPN B
Site 2
PE PE
CE CE
VPN B PE VPN A
Site 1 Site 2
CE
VPN A
iBGP VPNv4 VPN B
OSPF/BGP CE-PE Site 3
Site 3
L3VPN BUILDING BLOCKS

 Multiprotocol BGP (MP-BGP) is used to distribute VPN prefixes
and labels between PEs.
 VPNv4 Address Family
 PE-CE Routing Protocols:
 Static Route
 OSPF
 BGP
 Key Components:
 Virtual Routing and Forwarding (VRF)
 Route Distinguisher
 Route Targets
51
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
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.
 64-bit length
 RD + IPv4 prefix = VPNv4 prefix (96-bit), so that different customers
can use overlapping addresses
 Format:
 <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
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 any-
to-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
VPN A Export: 200:1 Site 1
CE
Site 1 CE
PE2
Import: 100:1 PE1

Export: 100:1
Import: 100:1
PE3 Export: 100:1
PE4 CE
VPN B Import: 200:1 VPN A
Site 2 Export: 200:1 Site 2
CE
54
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
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
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
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
 Manual Discovery
 LDP Signaling (RFC 4762)
 BGP Based VPLS
 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
Site 1 L2 header
CE1 PE1 PE2

Site 3
P1
CE3
PE3 MPLS backbone

Pseudowire
Site 2
CE – Customer's edge router
CE2 PE – Provider’s edge router
P – Provider's core router
58
VPLS BUILDING BLOCKS

 LDP or MP-BGP is used to distribute pseudowire labels
between PEs.
 LDP Based VPLS uses Targeted LDP
 BGP Based VPLS uses L2VPN Address Family
 PE-CE Attachment Circuit (AC):
 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
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 PE3
1
1
CE2 1 1 CE4
PE2
60
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
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
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
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.

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
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
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.
E
A C F
D
50Mbps traffic from A to F
B 50Mbps traffic from B to F
66
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.
E
A C F
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
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
TUNNEL PATH OPTION

 Tunnel path is routed based on routing table.
 Tunnel path: use-cspf=no and empty hops
 Statically configured explicit path.
 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
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
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.
71
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
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
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
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
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
IPV6 HEADER
 Version = 4-bit value set to 6.
 Traffic Class = 8-bit value.
 Replaces IPv4 TOS field
 Flow Label = 20-bit value.
 Payload Length = 16-bit value.
 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.
 Decreased by one every IPv6 hop (IPv4 TTL counter)
 Source address = 128-bit value.
 Destination address = 128-bit value.
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
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
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
IPV6 ADDRESSING REPRESENTATION

 16-bit fields in case insensitive colon hexadecimal
representation.
 2031:0000:130F:0000:0000:09C0:876A:130B
 Leading zeros in a field are optional, can be omitted.
 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.
 0:0:0:0:0:0:192.168.30.1 => ::192.168.30.1 =>:: C0A8:1E01
 Loopback address representation.
 0:0:0:0:0:0:0:1=> ::1
 Unspecified address representation.
 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
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
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
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
LINK-LOCAL
 Link-Local addresses used for:

 Communication between two IPv6 device (like ARP but at Layer 3)
 Next-Hop calculation in Routing Protocols
 Automatically assigned by Router as soon as IPv6 is enabled.
 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
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
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
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
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
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
 NDP is used to learn about all available IPv6 routers in the subnet
 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
 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
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
 Stateless address auto-configuration (SLAAC)

 Additional options with DHCPv6
 Stateful
 DHCPv6
 Static
 Manually assign the IPv6 address on the interface
90
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
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
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
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
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
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
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
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:
 2002:<client-public-ipv4>::/48
 For example, client with IPv4 address 103.97.110.10 is
connecting to a 6to4 relay, its IPv6 prefix will be:
 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
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
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):

 Assign IPv6 point-to-point address to each 6to4 tunnel
 Route a /56 User LAN prefix to each user’s 6to4 tunnel
 Tasks on TB Clients (Other routers):
 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
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
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
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
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 No Yes
instances per interface
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
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. Turn on IPv6 Address Family over IPv4 BGP session
2. 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
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

(CONT.)
 Run OSPFv3 between ISP backbone routers.
 The same as what you did with IPv4 OSPF
 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.
 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
LAB: DUAL-STACK ISP NETWORK –

WORKAROUND
 So what can we do?
 Workaround:
1. Manually configure static routes to all backbone router’s
Loopbacks, for BGP to look up
2. 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
THE END
THANKS FOR YOUR ATTENTION!
Contact Me
training@informationbeam.net
109

MTCINE WIZMASTER 20171103-20171108IPV6 Book PDF

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

MTCINE WIZMASTER 20171103-20171108IPV6 Book PDF

Hochgeladen von

Copyright:

Verfügbare Formate

MTCINE Bootcamp + IPv6 Workshop

CAGAYAN DE ORO, PHILIPPINES

 Areas of interest: BGP, MPLS, IPv6

 Discussion on RouterOS IPv6 implementation.

 For sure, be certified as MTCINE! 

MIKROTIK CERTIFICATIONS (CONT.)

MIKROTIK CERTIFICATIONS (CONT.)

MIKROTIK CERTIFICATIONS (CONT.)

 Morning 09:00 to 12:30

 Lunch break 12:30 to 14:00

CLASS SCHEDULE (CONT.)

 Topics beyond our scope are open to discuss at Q&A time.

 Open Shortest Path First (OSPF)

 Above topics are covered by MTCNA and MTCRE

BORDER GATEWAY PROTOCOL

AUTONOMOUS SYSTEM (AS)

 Typically one ISP is one AS.

AUTONOMOUS SYSTEM NUMBER (ASN)

BORDER GATEWAY PROTOCOL (BGP)

PATH VECTOR IMPLEMENTATION

PATH VECTOR IMPLEMENTATION (CONT.)

Add AS200 to the path

 Initial full routing table exchange between peers.

 Incremental updates after initial exchange.

 High extensibility to support new features, i.e. MP-BGP.

BGP MESSAGE TYPES

BGP SESSION & UPDATES

/routing bgp peer

 Verify BGP connectivity. Any state other than established

 Configurable from /routing bgp network.

IBGP & EBGP

EXTERNAL BGP PEERING (EBGP)

LAB: EBGP PEERING

 Configure your routers according to the topology.

 Advertise prefix 10.88.0.0/24 on R2.

INTERNAL BGP PEERING (IBGP)

 By default Nexthop is unchanged.

 iBGP speakers must be fully meshed:

 Eliminates dependency from physical interfaces and

LAB: IBGP PEERING

 Configure your routers according to the topology.

 BGP peer configuration:

LAB: EBGP MULTI-HOP WITH LOOPBACKS

AS100 172.16.1.1/24 172.16.1.2/24 AS200

 Configure your routers according to the topology.

 BGP peer configuration:

BGP BEST PATH

 BGP Multipath is a feature that allows BGP to install

BEST PATH SELECTION

BGP PATH ATTRIBUTES

BGP PATH ATTRIBUTES (CONT.)

BGP PATH ATTRIBUTES (CONT.)

 eBGP advertised nexthop is carried into iBGP.

 Weight is well-known AS200

 Can be manipulated for traffic engineering.

 Exchanged between AS and used to make decision

 IGP Metric is copied to MED when redistributed to BGP.

 Prefix origin is “incomplete”.

LAB: ROUTE DISTRIBUTION lo1: 10.200.0.1/22

 Configure your routers according to the topology.

 Redistribute static on R1.

 Redistribute connected on R2.

 Specify in BGP peer's configuration which chains to use