MPLS ATOM Interworking – Ethernet and IP

Interworking is the capability of L2TPv3 to change encapsulations between CE devices. The transport on one CE device can be translated to another transport. An example of this would be Frame Relay to Ethernet over an MPLS cloud.

Key points:

  • Ethernet Interworking can be used with IP and non-IP protocols
  • IP Interworking can only be used with IP

Example of Frame Relay to Ethernet Interworking (Ethernet)

PE1:
mpls ldp router-id Loopback0
mpls label protocol ldp
pseudowire-class CU1-MPLS-PW
encapsulation mpls
interworking ethernet

interface FastEthernet1/0
description connection to CU1A f0/0
no ip address
no cdp enable
xconnect 192.168.1.2 101 pw-class CU1-MPLS-PW
!
CU1A:
interface FastEthernet0/0
ip address 172.16.11.1 255.255.255.252
!

PE2:
frame-relay switching
no mpls traffic-eng auto-bw timers frequency 0
mpls ldp router-id Loopback0
mpls label protocol ldp
pseudowire-class CU1-MPLS-PW
encapsulation mpls
interworking ethernet

interface Serial2/0
no ip address
encapsulation frame-relay
serial restart-delay 0
frame-relay intf-type dce
no clns route-cache
!
connect frame-ethernet Serial2/0 101 l2transport
xconnect 192.168.1.1 101 pw-class CU1-MPLS-PW

CU1B:
bridge irb
interface Serial2/0
no ip address
encapsulation frame-relay
serial restart-delay 0
no clns route-cache
!
interface Serial2/0.101 point-to-point
frame-relay interface-dlci 101
bridge-group 1
!
interface BVI1
ip address 172.16.11.2 255.255.255.252
no clns route-cache

bridge 1 protocol ieee
bridge 1 route ip
!

Some outputs for verification:
CU1B#o
Codes: C – connected, S – static, R – RIP, M – mobile, B – BGP
D – EIGRP, EX – EIGRP external, O – OSPF, IA – OSPF inter area
N1 – OSPF NSSA external type 1, N2 – OSPF NSSA external type 2
E1 – OSPF external type 1, E2 – OSPF external type 2, E – EGP
i – IS-IS, su – IS-IS summary, L1 – IS-IS level-1, L2 – IS-IS level-2
ia – IS-IS inter area, * – candidate default, U – per-user static route
o – ODR, P – periodic downloaded static route

Gateway of last resort is not set

172.16.0.0/16 is variably subnetted, 3 subnets, 2 masks
C 172.16.11.0/30 is directly connected, BVI1
O 172.16.1.1/32 [110/65] via 172.16.11.1, 00:07:19, BVI1
C 172.16.1.2/32 is directly connected, Loopback0
CU1B#ping 172.16.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/35/52 ms

CU1A#o
Codes: C – connected, S – static, R – RIP, M – mobile, B – BGP
D – EIGRP, EX – EIGRP external, O – OSPF, IA – OSPF inter area
N1 – OSPF NSSA external type 1, N2 – OSPF NSSA external type 2
E1 – OSPF external type 1, E2 – OSPF external type 2, E – EGP
i – IS-IS, su – IS-IS summary, L1 – IS-IS level-1, L2 – IS-IS level-2
ia – IS-IS inter area, * – candidate default, U – per-user static route
o – ODR, P – periodic downloaded static route

Gateway of last resort is not set

172.16.0.0/16 is variably subnetted, 3 subnets, 2 masks
C 172.16.11.0/30 is directly connected, FastEthernet0/0
C 172.16.1.1/32 is directly connected, Loopback0
O 172.16.1.2/32 [110/2] via 172.16.11.2, 00:07:35, FastEthernet0/0
CU1A#ping 172.16.1.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/35/84 ms

PE1#sho mpls forwarding-table
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or VC or Tunnel Id Switched interface
16 Pop Label 10.1.102.0/31 0 Fa0/0 10.10.110.0
17 17 10.1.230.0/31 0 Fa0/1 10.1.120.1
18 10.1.230.0/31 0 Fa0/0 10.10.110.0
19 Pop Label 10.20.30.0/31 0 Fa0/1 10.1.120.1
20 21 192.168.1.2/32 0 Fa0/0 10.10.110.0
21 Pop Label 192.168.1.10/32 0 Fa0/0 10.10.110.0
22 Pop Label 192.168.1.20/32 0 Fa0/1 10.1.120.1
23 23 192.168.1.30/32 0 Fa0/1 10.1.120.1
24 No Label l2ckt(101) 25728 none point2point

PE2#sho mpls forwarding-table
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or VC or Tunnel Id Switched interface
16 17 10.1.120.0/31 0 Fa0/0 10.1.102.0
17 10.1.120.0/31 0 Fa0/1 10.1.230.0
17 Pop Label 10.10.110.0/31 0 Fa0/0 10.1.102.0
19 Pop Label 10.20.30.0/31 0 Fa0/1 10.1.230.0
20 20 192.168.1.1/32 0 Fa0/0 10.1.102.0
21 Pop Label 192.168.1.10/32 0 Fa0/0 10.1.102.0
22 23 192.168.1.20/32 0 Fa0/1 10.1.230.0
23 Pop Label 192.168.1.30/32 0 Fa0/1 10.1.230.0
25 No Label l2ckt(101) 17461 none point2point

PE1#sho mpls l2transport vc 101

Local intf Local circuit Dest address VC ID Status
————- ——————– ————— ———- ———-
Fa1/0 Ethernet 192.168.1.2 101 UP

PE2#sho mpls l2transport vc 101

Local intf Local circuit Dest address VC ID Status
————- ——————– ————— ———- ———-
Se2/0 FR DLCI 101 192.168.1.1 101 UP

PE1#sho mpls l2transport vc 101 det
Local interface: Fa1/0 up, line protocol up, Ethernet up
Destination address: 192.168.1.2, VC ID: 101, VC status: up
Output interface: Fa0/0, imposed label stack {25 21}
Preferred path: not configured
Default path: active
Tunnel label: 21, next hop 10.10.110.0
Create time: 00:17:30, last status change time: 00:11:56
Signaling protocol: LDP, peer 192.168.1.2:0 up
MPLS VC labels: local 24, remote 25
Group ID: local 0, remote 0
MTU: local 1500, remote 1500
Remote interface description:
Sequencing: receive disabled, send disabled
VC statistics:
packet totals: receive 502, send 320
byte totals: receive 31550, send 39537
packet drops: receive 0, send 0

PE2#sho mpls l2transport vc 101 detail
Local interface: Se2/0 up, line protocol up, FR DLCI 101 up
MPLS VC type is Ethernet, interworking type is Ethernet
Destination address: 192.168.1.1, VC ID: 101, VC status: up
Output interface: Fa0/0, imposed label stack {24 20}
Preferred path: not configured
Default path: active
Tunnel label: 20, next hop 10.1.102.0
Create time: 00:11:46, last status change time: 00:11:44
Signaling protocol: LDP, peer 192.168.1.1:0 up
MPLS VC labels: local 25, remote 24
Group ID: local 0, remote 0
MTU: local 1500, remote 1500
Remote interface description: connection to CU1A f0/0
Sequencing: receive disabled, send disabled
VC statistics:
packet totals: receive 190, send 448
byte totals: receive 18876, send 39750
packet drops: receive 0, send 0

PE1#sho mpls l2transport binding
Destination Address: 192.168.1.2, VC ID: 101
Local Label: 24
Cbit: 1, VC Type: Ethernet, GroupID: 0
MTU: 1500, Interface Desc: connection to CU1A f0/0
VCCV Capabilities: None
Remote Label: 25
Cbit: 1, VC Type: Ethernet, GroupID: 0
MTU: 1500, Interface Desc: n/a
VCCV Capabilities: None

PE2#sho mpls l2transport bind
Destination Address: 192.168.1.1, VC ID: 101
Local Label: 25
Cbit: 1, VC Type: Ethernet, GroupID: 0
MTU: 1500, Interface Desc: n/a
VCCV Capabilities: None
Remote Label: 24
Cbit: 1, VC Type: Ethernet, GroupID: 0
MTU: 1500, Interface Desc: connection to CU1A f0/0
VCCV Capabilities: None

PE1#sho mpls l2transport hw-capability interface fastEthernet 0/0
Interface FastEthernet0/0

Transport type FR DLCI
Core functionality:
MPLS label disposition supported
Control word processing supported
Sequence number processing not supported
VCCV Type 1 processing supported
Edge functionality:
Not supported

<deleted>

Example of Frame Relay to Ethernet Interworking (IP)

PE1:
mpls ldp router-id Loopback0
mpls label protocol ldp
pseudowire-class CU1-MPLS-PW
encapsulation mpls
interworking ip
!
interface FastEthernet1/0
description connection to CU1A f0/0
no ip address
duplex auto
speed auto
no cdp enable
no clns route-cache
xconnect 192.168.1.2 101 pw-class CU1-MPLS-PW

PE2:
frame-relay switching
no mpls traffic-eng auto-bw timers frequency 0
mpls ldp router-id Loopback0
mpls label protocol ldp
pseudowire-class CU1-MPLS-PW
encapsulation mpls
interworking ip
!
interface Serial2/0
no ip address
encapsulation frame-relay
serial restart-delay 0
frame-relay intf-type dce
no clns route-cache
!
connect frame-ethernet Serial2/0 101 l2transport
xconnect 192.168.1.1 101 pw-class CU1-MPLS-PW

CU1A:
interface FastEthernet0/0
ip address 172.16.11.1 255.255.255.252
duplex auto
speed auto
no clns route-cache

CU1B:
interface Serial2/0
ip address 172.16.11.2 255.255.255.252
encapsulation frame-relay
ip ospf network broadcast ! note the need to ensure OSPF network types are compatible on both sides.
serial restart-delay 0
frame-relay map ip 172.16.11.1 101 broadcast
no clns route-cache
!
PE1#sho mpls l2transport vc 101 detail
Local interface: Fa1/0 up, line protocol up, Ethernet up
MPLS VC type is IP, interworking type is IP
Destination address: 192.168.1.2, VC ID: 101, VC status: up
Output interface: Fa0/0, imposed label stack {25 21}
Preferred path: not configured
Default path: active
Tunnel label: 21, next hop 10.10.110.0
Create time: 00:28:49, last status change time: 00:16:38
Signaling protocol: LDP, peer 192.168.1.2:0 up
MPLS VC labels: local 18, remote 25
Group ID: local 0, remote 0
MTU: local 1500, remote 1500
Remote interface description:
Sequencing: receive disabled, send disabled
VC statistics:
packet totals: receive 1963, send 977
byte totals: receive 121260, send 118233
packet drops: receive 0, send 0

PE2#sho mpls l2transport vc 101 detail
Local interface: Se2/0 up, line protocol up, FR DLCI 101 up
MPLS VC type is IP, interworking type is IP
Destination address: 192.168.1.1, VC ID: 101, VC status: up
Output interface: Fa0/0, imposed label stack {18 20}
Preferred path: not configured
Default path: active
Tunnel label: 20, next hop 10.1.102.0
Create time: 00:21:53, last status change time: 00:16:55
Signaling protocol: LDP, peer 192.168.1.1:0 up
MPLS VC labels: local 25, remote 18
Group ID: local 0, remote 0
MTU: local 1500, remote 1500
Remote interface description: connection to CU1A f0/0
Sequencing: receive disabled, send disabled
VC statistics:
packet totals: receive 119, send 81
byte totals: receive 9492, send 8786
packet drops: receive 0, send 0

CCDE TOPIC: L2TPv3 & ATOM

L2TPv3 is a tunneling protocol similar to GRE
ATOM is L2TPv3 over MPLS

Here are some highlights:

  • Does not support Layer 3 protocols – this is Layer 2 only. GRE supports Layer 3
  • Does not require MPLS
  • Can change encapsulations between CE routers. For example, PPP to Ethernet is supported (this is called interworking)
  • Has support for ‘cookies’ which help avoid spoofing
  • Data/Control plane separation
  • Supports local switching as well

Technical details:

  • IP protocol type 115
  • L2TPv3 adds several bytes of overhead (4)
  • Fragmentation is supported pre-tunnel
    • important to do this at the edge
    • 12.0(24)S introduces the pre-tunnel fragmentation
      • this avoids the remote PE reassembly
    • ip pmtu in the pseudowire-class
    • ip dfbit set in the pseudowire-class (forces a drop / ICMP if packet too big)
  • Tunnel selection supported
    • Unidirectional – similar to TE
    • destinations must be /32 loopbacks
    • preferred-path under pseudowire-class
    • must configure traffic engineering

Quality of Service

  • Supported under MQC
    • classification based on CoS or VLAN only – no support for DSCP
    • maps to EXP in MPLS or IP DSCP
    • marks on layer 2 fields – Ethernet 802.1p, FR = FECN/BECN (outbound to CE only)
  • Supports multiple color policers

Interworking

  • Ethernet
    • native service is Ethernet
    • CEs may be required to use bridging (if using FR/ATM/HDLC/PPP) – IRB or RBE
    • Supports IP and other protocols
  • IP
    • Supports only IP
    • Simpler CE configuration possibly

Debugs

  • show mpls l2transport vc
  • debug mpls l2transport signaling message

References

  • http://www.faqs.org/rfcs/rfc3931.html

Here’s a basic example of L2TPv3 tunneling:

PE1:
l2tp-class CU1
password 7 11081B06464058
!
pseudowire-class CU1-PW
encapsulation l2tpv3
sequencing both
interworking ip
protocol l2tpv3 CU1
ip local interface Loopback0
!
interface FastEthernet1/0
no ip address
duplex auto
speed auto
no cdp enable
no clns route-cache
xconnect 192.168.1.2 103 encapsulation l2tpv3 pw-class CU1-PW

PE2:
l2tp-class CU1
password 7 00051105550958
!
pseudowire-class CU1-PW
encapsulation l2tpv3
interworking ip
protocol l2tpv3 CU1
ip local interface Loopback0

interface FastEthernet1/0
description connnection to CU1B f0/0
no ip address
duplex auto
speed auto
no cdp enable
no clns route-cache
xconnect 192.168.1.1 103 encapsulation l2tpv3 pw-class CU1-PW

Here’s a basic example of AToM, bridging Frame-Relay to Ethernet

PE1:

frame-relay switching
!
l2tp-class CU1
password 7 00051105550958
!
pseudowire-class CU1-PW
encapsulation l2tpv3
interworking ip
protocol l2tpv3 CU1
ip local interface Loopback0
!
interface Serial2/0
no ip address
encapsulation frame-relay
serial restart-delay 0
clockrate 2016000
frame-relay intf-type dce
!
connect ethernet-fr Serial2/0 100 l2transport
xconnect 192.168.1.2 300 pw-class CU1-PW

CU1A:

interface Serial2/0
ip address 172.16.111.1 255.255.255.252
encapsulation frame-relay
ip ospf network broadcast
serial restart-delay 0
frame-relay map ip 172.16.111.2 100 broadcast

PE2:
l2tp-class CU1
password 7 1513090F557878
!
pseudowire-class CU1-PW
encapsulation l2tpv3
interworking ip
protocol l2tpv3 CU1
ip local interface Loopback0
!
interface FastEthernet1/0
description connnection to CU1B FastEthernet0/0
no ip address
no cdp enable
xconnect 192.168.1.1 300 encapsulation l2tpv3 pw-class CU1-PW

CU1B:
interface FastEthernet0/0
ip address 172.16.111.2 255.255.255.252

Changes for PPP -> Ethernet

PE1:
interface Serial2/0
no ip address
encapsulation ppp
serial restart-delay 0
clockrate 2016000
no cdp enable
xconnect 192.168.1.2 300 encapsulation l2tpv3 pw-class CU1-PW


Share/Save/Bookmark

Best Practice: Don’t use bandwidth statement

It’s considered a best practice to not configure the ‘bandwidth’ statement on physical router interfaces. This is because the routing protocol will throttle updates propagated through this interface. The one case where you’ll need to consider configuring the bandwidth statement is on Tunnel interfaces. This is because the default bandwidth of a Tunnel interface is 9.6kbps.

Reference: IOS Interface Configuration Guide

Share/Save/Bookmark

A note on versions

Greg over at networkgremlins hand an interesting insight into the features in IOS versions. It’s primarily concerned with the SP lab, but will apply to any CCDE lab they set up as well… depending on the IOS version.

Check it out here.

Share/Save/Bookmark

Installing VMWARE Server 1.0.5 on Ubuntu 8.04 – 64 bit edition

apt-get install build-essential
apt-get install ia32-libs
apt-get install xinetd
apt-get install kernel-package

sudo touch /etc/vmware/ssl/rui.key
sudo touch /etc/vmware/ssl/rui.crt

download http://vmkernelnewbies.googlegroups.com/web/vmware-any-any-update-116.tgz

unzip/untar & run runme.pl

sudo cp /lib/libgcc_s.so.1 /usr/lib/vmware/lib/libgcc_s.so.1/
sudo cp /usr/lib/libpng12.so.0 /usr/lib/vmware/lib/libpng12.so.0/

Fast Hellos

One thing to think about from a design perspective is the scalability of fast hellos. If you have a router with several hundred interfaces, each sending subsecond hellos, the RP has to process a lot of hello packets. If you can design your network to have point-to-point interfaces, the interface flap will most likely be quicker and a more scalable way of detecting failures. If you can’t do this you may want to look into Bidirectional Forwarding Detection (BFD). BFD is protocol independent, so it can signal multiple interface protocols in the event of a failure.

References:
BFD
OSPF Support For Fast Hello Packets

Share/Save/Bookmark

Multicast Notes

The amount of multicast on the outline is a bit sparse, so to speak. Sorry, I just couldn’t resist. Anyway, with this in mind, there are just a few things to note with respect to multicast design.

  1. Don’t use Dense mode. Only use Sparse.
  2. When using Anycast-RP, or any design where you’re using multiple loopbacks, it’s a best practice to hardcode the router id in your IGP.
  3. If you can use Anycast-RP and AutoRP together, do it.
  4. A new alternative to the RP of last resort is no ip pim dm-fallback

Sparse mode requires a Rendezvous Point (RP) to hold the shared tree information. There are several ways of assigning RPs. You can use AutoRP, BSR, or Anycast-RP.

AutoRP requires candidate RPs and mapping agents, which can be set up with the commands:

ip pim send-rp-announce scope #
ip pim send-rp-discovery scope #
ip pim autorp listener (required since you’ll be using sparse mode)
no ip pim dm-fallback (so it won’t fall back to dense mode)

Also note that the interface or IP address you use must be reachable via IGP.

Some outputs:

R101 is the RP and Mapping Agent:

R101#sho ip pim rp map
PIM Group-to-RP Mappings
This system is an RP (Auto-RP)
This system is an RP-mapping agent (Loopback0)

Group(s) 224.0.0.0/4
RP 192.168.0.1 (?), v2v1
Info source: 192.168.0.1 (?), elected via Auto-RP
Uptime: 01:04:06, expires: 00:02:13

BSR is another RP mechanism – BSR stands for BootStrap Router. You can configure it like so:

ip pim bsr-candidate
ip pim rp-candidate
no ip pim dm-fallback

Anycast RP is an RP mechanism where you configure the same RP address on multiple routers. You then need to ensure all routers in your topology have this IP address configured statically as their RP.

On the RP’s:
ip pim rp-address 10.1.1.1
interface loopback10
ip address 10.1.1.1 255.255.255.255
interface loopback0
ip address 192.168.0.1 255.255.255.255
ip msdp peer 192.168.0.2 connect-source loopback0
ip msdp originator-id loopback0

You can also combine AutoRP and Anycast RP to avoid the configuration of an RP address on every router.

References:

Cisco IOS 12.4T IP Multicast Configuration Guide

Verifying IP Multicast Operation


Share/Save/Bookmark

Fast Convergence Techniques

In reading the SRND on router access layer there are a few key takeaways.
On page 5 it says: “Cisco recommends a routed network core in all cases.”

Let’s examine the reasoning behind this statement. First of all, what’s the alternative? You can have a layer-2 core where your devices simply switch frames at layer-2. Think about the problems with this design.

  1. Troubleshooting is hard
  2. Traffic is not as deterministic
  3. Engineering based on metrics is difficult

Why do I think troubleshooting is harder than layer-3 networks? Think about the tools you have available to you to troubleshoot layer-2 issues. You’ve got CAM tables, spanning-tree outputs, and CDP/LLDP messages. That’s about it. Layer-2 ping exists but what’s the next step if that fails? Layer-3 networks have a lot more management and troubleshooting tools available.

Traffic is not necessarily deterministic either. You rely on the spanning-tree algorithms to determine a loop-free path through the network. This means manipulation of root bridges and link costs. It’s difficult to ensure a particular path in the event of a failure. You need to ensure you know which ports are blocking/forwarding and so on. Layer-3 cores don’t have this problem – all links can be forwarding.

I would argue that traffic engineering is difficult as well. You have MST where you can select particular VLANs to remain forwarding on a set of links, with the other VLANs forwarding on a different set of links, but that’s difficult to scale. Layer-3 networks have an easier time for traffic engineering, with a standard set of tools to implement and troubleshoot them.

With that said, let’s examine some of the other items in the SRND with respect to the CCDE written outline.

  1. Layer 2 Down Detection – use point to point fiber connections where possible because the detection of failure is very quick. You should also examine the topics of debounce and carrier-delay. With this you should also implement ip event dampening on all interfaces to minimize disruption to your network during multiple failures. The dampening feature is very similar to BGP’s route dampening feature.
  2. For all media types – SONET and point-to-point fiber are both very fast, other media types are not quite as quick to detect. If you can, use BFD on any interfaces as this will decrease the detection of failures. In multipoint networks this may be the only way to have subsecond failure detection.
  3. Fast hello timers – OSPF and EIGRP provide the following:
    1. OSPF: ip ospf dead-interval minimal hello-multiplier # (typically 4)
    2. EIGRP:
      1. ip hello-interval eigrp 1
      2. ip hold-time eigrp 3
  4. OSPF, EIGRP, IS-IS, BGP – IS-IS will need further research, but I guess it has similar mechanisms as OSPF. BGP has several things that can be tweaked to decrease convergence time:
    1. bgp path mtu
  5. Fast SPF Timers – OSPF has several in the SRND:
    1. SPF throttle tuning
      1. timers throttle spf
      2. Best practice: 10 100 500
    2. LSA throttle tuning
      1. timers throttle lsa
      2. Best practice: 10 100 5000
  6. OSPF, IS-IS – this may be a typo?
  7. Recursion and Convergence – the issue they’re talking about here is the fact that OSPF’s convergence will increase as more routers exist in the network. You can increase the amount of links/routes within the OSPF area without taking as major of a hit as an increase in the amount of routers. The SPF calculation recurses on each type 1 LSA created by every router in the network, which will increase convergence time.
  8. Impact of Third Party Next Hop & BGP recursion – have a look at this diagram.


Share/Save/Bookmark

Abstraction, Layering, and a little Anycast

Ok, so the post from yesterday asked you to look at a diagram and determine where a packet would route and why it might take that path. Hopefully some of you have had a chance to lab it up to test any theories you have. Even if you haven’t we can still have a look and draw some logical conclusions.

We know from the diagram that 10.0.0.1/32 is directly connected to R1, so no matter what, it will take the directly connected path. However, R2 will learn about the 10.0.0.1/32 prefix via IGP (OSPF) and EGP (BGP). The default eBGP administrative distance is 20, whereas OSPF is 110. My initial thought is that if R2 learns about 10.0.0.1/32 via eBGP as well as OSPF, eBGP will be preferred because of the lower AD. To some extent this is true. If you choose to not advertise the 10.0.0.1 prefix to eBGP neighbors, then it will be preferred via eBGP. However, once you include the network statement, it will choose the IGP path.

Here are some outputs:

R1 (show ip route):

C 10.0.0.1/32 is directly connected, Loopback1

R2 (show ip route, show ip bgp, show run):

O 10.0.0.1/32 [110/11] via 10.1.34.2, 09:14:11, Ethernet0/1

(10.1.34.2 is the IGP neighbor advertising this prefix):


BGP table version is 2, local router ID is 192.168.0.3
Status codes: s suppressed, d damped, h history, * valid, > best, i – internal, r RIB-failure, S Stale
Origin codes: i – IGP, e – EGP, ? – incomplete

Network Next Hop Metric LocPrf Weight Path
* 10.0.0.1/32 10.1.13.1 0 0 100 i
*> 10.1.34.2 11 32768 i

router bgp 200
no synchronization
bgp log-neighbor-changes
network 10.0.0.1 mask 255.255.255.255
neighbor 10.1.13.1 remote-as 100
no auto-summary

Watch what happens when I remove the ‘network’ statement:

R2 (show ip route):

B 10.0.0.1/32 [20/0] via 10.1.13.1, 00:00:06

It’s being learned via eBGP!

This could be a problem depending on whether you want to advertise this prefix to your eBGP neighbors. You can use the network backdoor command so the router will prefer IGP learned routes over eBGP learned routes, but this command will not advertise the network to your eBGP neighbors. You’ll get a rib-failure – shown below in the output from show ip bgp:


Network Next Hop Metric LocPrf Weight Path
r> 10.0.0.1/32 10.1.13.1 0 0 100 i

When designing networks, you must have deep knowledge of how protocols operate and interact with other protocols. The BGP/IGP interaction is one of these, and this is just a small example.

Share/Save/Bookmark

Network Topology Abstraction & Layering

The whole concept of abstraction has been pounded into my brain since beginning study in CS – over 15 years ago now. Abstraction permits our tiny minds to more clearly see the big picture and solve large problems. Creating block diagrams before moving into detailed design diagrams is critical to ensuring our designs can scale. However, abstraction is not without its own issues.

When you reduce your problem to an abstraction, you lose information – you effectively ‘hide’ information that might be critical to ensuring scalability. Abstracting the problem into block form also requires you to have deep knowledge of the protocols involved. Let me give you an example of a problem I recently encountered.

This issue relates to the previous post on Anycast addresses. Refer to the following diagram and see if you can figure out where a packet will travel.

Going from “host” and destination: 10.0.0.1, what happens when the packet reaches R2?

The answer (with some outputs) comes tomorrow. Send me an email or feel free to comment..

Share/Save/Bookmark