Category: Routing

RT & RD difference

  • It’s given that customers of a Service Provider will have overlapping IP addressing in their VPNs, e.g. you will have more than two customers who use the 10.0.0.0/8 network.  The RD is how you tell them apart.  If you have customer “A” with RD “A” and customer “B” with RD “B” the routes “A:10.0.0.0/8” and “B:10.0.0.0/8” become unique.  This is all the RD does.

What is an RD? An RD is a 64 bit value that is attached to the customer’s IPv4 address, to make it a Unique 96 bit address called VPNv4. These addresses are ONLY exchanged between the PE routers.

Once the PE router attaches the RD to the CE routes, it then sends the VPNv4 address/es to the other PE router/s. The receiving PE router strips the RD from the VPNv4 prefix, and it s left with an IPv4 address.

  • The Route Target tells you which VRF table the route belongs to.  You have to separate the two attributes because sometimes you want the same route to belong to multiple VRF tables.   This is common in what’s known as “Central Services VPNs”. For example if the Service Provider hosts email for customers, that route to the mail server would have to be in the routing table of multiple customers.  This doesn’t break the rule of the route having to be unique though, which is what the RD does.

NOW  How does the receiving PE know which VRF does the IP address belong to? The answer is  Route-Target .

The  Route-target  is a BGP extended community that indicates which routes should be exported from a given VRF or imported into a given VRF.

Share this!

IPExpert CoD: MPLS-VPN

This post contains my notes from an old version of IPX Class on Demand by Joe Astorino.

RD has no special meaning—it is only used to make potentially overlapping IPv4 addresses globally unique

Route Targets are additional attributes attached to VPNv4 BGP routes to indicate VPN membership

Export Route Targets identifying VPN membership are appended to customer route when it is converted into VPNv4 route

RD & RT are extended BGP communities; neighbor send-community extended is required!

RR for VPNv4 does not need to be the same as RR of IPv4.

PE imposes 2 labels, the one if from LDP, and the bottom one is from VPNv4 address-family.

Each bgp address-family is a different RIB.

  • Import policy means that routes will come from the VPN extended community
  • Export policy means that routes will go to the VPN extended community

ARF –Automatic Route Filtering:  Only VPN information matching a locally configured RT will be imported
Could be disabled: no default bgproute-target filter

By default, when running OSPF over Frame-Relay and network type is anything except point-to-multipoint, on a spoke, the nexthop for a route originated  from another spoke will be that spoke.
But when the network type is point-to-multipoint, the nexthop will be the hub, and a host route for each spoke will exist.
So make sure to use point-to-multipoint when using MPLS.

RIP/EIGRP address-family version and summarization is different form the RIP/EIGRP’s itself.

When the customer needs the same AS on multiple sites, the AS Override feature should be triggered. So the PE will override its (prepend). Another way to handle this requirement is using allowas-in. Continue reading “IPExpert CoD: MPLS-VPN”

Share this!

IPExpert CoD: MPLS & LDP

This post contains my notes from an old version of IPX Class on Demand by Joe Astorino.

# hiding MPLS topology by just incrementing TTL 1 time when reaching the CE
router(config)# no ip mpls propagate-ttl

MPLS MTU is automatically decreased on LAN interfaces and increased on WAN interfaces.

Default mpls mtu is 1512 which supports 3 labels; MPLS MTU can be set by mpls mtu x

LDP router-id should be routable on network.

Connected routes are advertised as implicit-null label for PHP on upstream router

router(config)# mpls ldp neighbor ip labels accept acl
router(config)# mpls ldp tcp pak-priority //Kinda like setting QoS for LDP
!
#Like "ip accounting"
router(config-if)# mpls accounting experimental input/output
router(config-if)# mpls netflow egress
!
router# show mpls ldp binding // LIB
router# show mpls forwarding table // LFIB
router# show ip route // RIB
router# show ip cef ip detail //FIB

To clear LIB:

router(config)# no mpls ip
router(config)# mpls ip

PHP is the default.

Share this!

MPLS Building Blocks

IP routers make forwarding decision based on IP packet header, and local CEF and FIB table.
MPLS routers make forwarding decision based on the MPLS label and the LFIB .
MPLS is great technology these days not because it forwards the packets faster , but because of applications and solutions we can provide for our customers like MPLS VPN’s .

MPLS uses the IP routing information to determine the direction and next hop to forward a labeled packet .

Does this before the first packet even arrives.

Continue reading “MPLS Building Blocks”

Share this!

Default-route in EIGRP

I know it’s not such tricky thing, but to have in mind…

There are two solutions to originate 0.0.0.0/0 in EIGRP:

  1. (My preferred one) Static 0.0.0.0 0.0.0.0 pointing to an Interface (not next-hop) + network 0.0.0.0
    This way, there is no need of “auto-summary”, so you can use it switched off.
  2. Static 0.0.0.0 0.0.0.0 pointing to next-hop + “auto-summary” + “ip default-network“
Share this!