Subido por service.enics

pdfcoffee.com mtcine-ip-6-nstructor-pdf-free

Anuncio
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
training@informationbeam.net
109
Descargar