It is just 6 months away from the next Cisco Live US event, my how time flies.  I just wanted to take a moment and share a quick link with you on the event – they (Cisco Live) is asking for your help in choosing the next bag – you can find the poll here: http://t.co/gWgIxc4b

Some quick images can be seen here, you can see more detailed images on their site.  They do say that these are NOT the actual bag, nor to scale – but ideas that they are looking at.

My personal preference looking at these is either the backpack or the duffle bag.  To be honest, the Duffle Bag might actually make some more sense – it will help get all the freebies home (More space).  But, a backpack is always a safe bet.

See what happens in June!

Well, it has finally come time for me to make a new start in my professional life. Recently I have resigned from my position – Manager of US Network Engineering -at my former employer, KGB. Now, I work for NTT America (www.ntta.com) as Senior Network Engineer, Data Center Services (www.dedicatedserver.com ) . In my new role I will be working with some of the latest technology, cutting edge soltions, data center design, and just all around uber geek stuff. This will be a big change from what I was doing – Managing a team as well as being the Sr Network Engineer, but NTTA is the right place for me to be.

I have neglected the blog for a few weeks and now I hope you understand why. Transitioning from one job to another can be difficult at best – I was with KGB for over 12 years. I wanted to make sure that the team that is left behind had the knowledge, to the best of their ability, to understand some of what was done and what is being done. They are in the middle of a huge data center project right now, and losing any member of a team is difficult, so I wanted to make sure that they would be OK.

I am back now, so it is time to get the party started!

Thank you.

On October 26th I attended the OpenFlow Symposium in San Jose, CA hosted by Packet Pushers and TechFieldDay at the DoubleTree San Jose. The purpose of this symposium was to help gain more exposure to OpenFlow as well as discuss what some of the major players see and feel about the technology. In attendance was representatives from Big Switch Networks, Brocade, Cisco, Google, Juniper, NEC, and Yahoo!. They each were allowed to present their views and feelings and then the panel was opened up for discussion and questions.

My take was that Google and Yahoo! are big into this technology as they have the most to gain from it.  They run warehouse size data centers all over the world, and this type of technology has a huge benefit to them as it means they can develop their own controllers and control merchant silicon, thus releasing them from relying on other vendors network hardware to support their data center. Not only that, but they can help prioritize and track individual flows based on what the user is doing. For example – a person who is placing items in their carts and heading to checkout can have a higher priority flow over someone just looking around.  The speed to finish the transaction is important to them, not to mention they can also secure that traffic in the network differently then a person who is just looking.

Cisco, Juniper, Brocade, Big Switch, and NEC are all interested in this technology and have basically committed to have support for it.  The gentlemen from Cisco and Juniper showed their excitement and enthusiasm for the protocol – NEC did one better, they have it in the field!  Now, I am sure that Cisco and Juniper have it out there as well in field trials, but NEC was able to say they have a shipping product already.

So, as you can see, OpenFlow has the vendors attention.  They see the benefits of what this can bring to a Service Provider or a Campus, but I am still debating the impact for the Enterprise.  My previous post on OpenFlow shows how you can use it, but it might be a bit too complex for a standard Enterprise to want to support.  Places where you are multi-tenant, like SP networks and College Campuses, it has great potential for being able to segment traffic as well as provide a playground for testing without impacting a production network.  To be honest, I have seen colleges do something similar with MPLS and segmenting traffic and protocols away from departments, so OpenFlow is definitely a technology they can deploy as well and make the network more dynamic where need be.

Here are links to other posts on this same topic from people who attended the symposium:

Ethan Banks – OpenFlow State of the Union

Tony Mattke – The OpenFlow Symposium

Derick Winkworth – More Open Flow Symposium Notes…

If I did not list your blog and you would like it added, please let me know.

Below are the vendors presentation for your viewing pleasure.  Thanks to Stephen Foskett and Tech Field Day for providing these vidoes:

Stephen Foskett and Greg Ferro Introduce the OpenFlow Symposium from Stephen Foskett on Vimeo.

Igor Gashinksy of Yahoo! At OpenFlow Symposium from Stephen Foskett on Vimeo.

Ed Crabbe of Google at OpenFlow Symposium from Stephen Foskett on Vimeo.

Kyle Forster of Big Switch Networks at OpenFlow Symposium from Stephen Foskett on Vimeo.

Curt Beckmann of Brocade presents at the OpenFlow Symposium, San Jose, October 26, 2011 from Stephen Foskett on Vimeo.

David Meyer of Cisco at OpenFlow Symposium from Stephen Foskett on Vimeo.

Don Clark of NEC at OpenFlow Symposium from Stephen Foskett on Vimeo.

David Ward of Juniper at OpenFlow Symposium from Stephen Foskett on Vimeo.

OpenFlow Symposium Morning Questions from Stephen Foskett on Vimeo.

Ivan Pepelnjak’s Technical Q&A from OpenFlow Symposium from Stephen Foskett on Vimeo.

An OpenFlow Symposium was held in San Jose, CA on October 26th, 2011 and hosted by by PacketPushers.Net and TechFieldDay.Com. This was my first true exposure to the OpenFlow protocol and concepts of SDN (Software Designed Networking), and it was a great exposure.

If you are not familiar with OpenFlow or SDN, please let me take a moment and give you a brief overview and a quick scenario. OpenFlow is a way in which you can have a application – called a Controller – maintain and control switch flow tables. This controller is aware of all flows in the topology of its domain, the domain being the switches/ports that it controls. Yes, you can have specific ports on a switch controlled via the controller, and all the other ports as part of a normal network that is controlled via the switch. OpenFlow will have no impact to the other ports, they will continue to operate just like nothing was different.

A good use case for OpenFlow is Multi-Path Layer 2 switching in a data center or other high bandwidth location. With normal multi-patch technologies one of the links is blocked via STP, thus sitting idle just waiting for the primary link to fail. With OpenFlow, the controller is aware of all paths in the network and able to load the traffic accordingly. Lets take a look at the following diagram:

As you can see we have 3 switches in this network (X, Y, and Z), 2 FTP servers (FTP 1 and FTP 2), 2 FTP Clients (Client 1 and Client 2), as well as some links between each switch (A, B, and C). In a normal STP Network, assuming Switch Y was the root, the C Link between Switch X and Switch Z would be in a blocking mode. If this was a 10G link, that would be quite a bit of money wasted. With OpenFlow the controller is aware of all of these links. If Client 1 starts a transfer to FTP 1, the OpenFlow controller would build a flow patch via A link. When Client 2 starts its transfer, the controller builds a flow path over the C link. What also happens is that the overall speed and transfer rates are improved since you are not “sharing bandwidth” with the other FTP application.

There are many other use cases for OpenFlow besides this one – some include that you can use it for Virtualization and moving servers as the controller can move the flow; the potential to move the certain traffic to an inspection device (IDS/IPS/Firewall) while allowing other traffic to bypass; ability to move flows (TCP session) around as needed for load balancing; or prioritize traffic to provide best speeds; etc.

Some good links for OpenFlow Information:

CloudToad on PacketPushers

PacketPushers Podcast Show 68

OpenFlow.Org

IOS Hints

Well, the week has come – its time for Network Field Day #2 as well as OpenFlow Symposium that is being hosted by Gestalt IT and PacketPushers.Net.  This is going to be a week of drinking from the firehose, that is for sure – but I would not have it any other way!

The OpenFlow Symposium is on Wednesday, 10/26 – the Network Field Day is on 10/27 and 10/28.  Both events will be streamed, and below are the streams for your viewing pleasure.

Or, you can check them out at:

This was posted on twitter today and just had to share it with you.  It takes a few moments until you see what is so funny, but just wait – you will cry laughing.

This is a different type of post – one that I have not done here before but have considered for quite some time – it is an opinion post. I will occasionally take a few moments and explain my view of a topic that is hot in the news, world, or perhaps something that is being discussed on Twitter / Facebook / Google+.

It is not my intention to offend anyone, persuade anyone, or change your mind – but more of an avenue for my to spill my thoughts and feelings.

Ok, pleasantries out of the way now – lets get onto the topic here: Personal View – BoA ATM/Visa Fee

So, Bank of America wants to charge its “customers” a $5 fee per month that they use their debit/visa card for purchases unless you maintain $20,000 in deposits or have a mortgage with them ( NY Times 9/30/2011 ). They are joining all the other banks that are doing this or talking about it as well – Chase, Wells Fargo, and others – and all this is because the government has imposed limits on fees charged to merchants. Since the government has decided to step in and “protect the merchant” from extra fees, those fees are being made up on the consumer now. Of course, the merchants are not lowering prices on their items, so we can see how well that all worked out for us now, eh? But I digress.

The initial reaction I had to this fee news was WHAT!?!? That does not sound fair considering the average American does not know how to save any money. It sounded like Bank of America was trying to cheat and steal from the little guy out there – the single mom who is working two jobs to raise her child; the dad who’s wife has passed away and now needs to raise their children alone; the family who has fallen on hard times and is dipping into savings; or the average American who just spends and spends. Yet the more that I thought about this who concept, the more that I started to see a different side of it.

What side is that? Well, perhaps this is what the average American actually needs. Today most people do not track their spending, they just monitor the available cash in their account or rely on overdraft protection. That $10 lunch here, $15 lunch there, that shopping trip where they just put things in the cart as they know they have money in the bank, the kid who asks to have a new tow, all add up but never really get tracked by the average person. As long as they have money in the account, they use their Visa/Debit card. Granted, that has help some people to avoid credit card debt, but the flip side of it is that people do not track their expenses. We spend money that we have, not save it.

I am hoping that this new fee will make people think before a purchase – do I really need to go out to lunch every day or can I pack and save that fee? Perhaps people will start using cash again, there is no fee for using the BoA ATM with your ATM card – grab cash and go shopping. Not enough cash, then you do not buy that extra stuff. Perhaps this is what some Americans need to start saving money to prepare for retirement, to balance their budgets, to stop spending on things that are worthless. Who knows, maybe we can use this to learn and make things better for the average American.

Just something I was thinking and wanted to share. Please feel free to comment if you wish.

In continuation of my previous posts on MPLS, lets talk about EIGRP as the PE to CE protocol.

Now while one might initially think that this is just as easy as RIP and Static routes, there are some added complexities with EIGRP. What complexities am I referring to? Well when configuring EIGRP on a PE router one needs to be aware of the Autonomous System number relationship. Normally you just create router eigrp AS and that is all you do, but when you have a PE router you need to use the address-family command and then specifically the autonomous-system # for that VRF. This has a big of complexities, but nothing that is a big deal. Just one more thing to remember.

So, lets add EIGRP AS 14 to VRF Green (R1 and R4) as well as the PE (R2 and R5) and configure redistribution. For reference I have already removed the RIP configurations.

First up, the CE routers:

R1:
Rack1R1(config)#router eigrp 14
Rack1R1(config-router)#no au
Rack1R1(config-router)#net 192.168.253.1 0.0.0.0
Rack1R1(config-router)#net 192.168.21.1 0.0.0.0

R4:
Rack1R4(config)#router eigrp 14
Rack1R4(config-router)#no au
Rack1R4(config-router)#net 192.168.253.4 0.0.0.0
Rack1R4(config-router)#net 192.168.54.4 0.0.0.0

And now the PE routers. Just have to remember that we need to use Address Family here as well as configured redistribution under BGP

R2:
Rack1R2(config)#router eigrp 1
Rack1R2(config-router)#address-family ipv4 vrf Green
Rack1R2(config-router-af)#autonomous-system 14
Rack1R2(config-router-af)#net 192.168.21.2 0.0.0.0
*Sep 12 15:00:13.049: %DUAL-5-NBRCHANGE: IP-EIGRP(1) 14: Neighbor 192.168.21.1 (Serial4/0.21) is up: new adjacency
Rack1R2(config-router-af)#redistribute bgp 1 metric 100 100 255 1 1500
Rack1R2(config-router-af)#router bgp 1
Rack1R2(config-router)#address-family ipv4 vrf Green
Rack1R2(config-router-af)#redistribute eigrp 14

Real quick we should check the VPNv4 tables on R2 to make sure that we see what we expect to see:
Rack1R2#sh ip bgp vpnv4 vrf Green
BGP table version is 51, local router ID is 220.61.253.2
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
Route Distinguisher: 1:14 (default for vrf Green)
*> 192.168.21.0 0.0.0.0 0 32768 ?
*>i192.168.54.0 220.61.253.5 0 100 0 ?
*> 192.168.253.1/32 192.168.21.1 2297856 32768 ?
Rack1R2#

Looks good, now onto R5!

R5:
Rack1R5(config)#router eigrp 1
Rack1R5(config-router)#address-family ipv4 vrf Green
Rack1R5(config-router-af)#no au
Rack1R5(config-router-af)#autonomous-system 14
Rack1R5(config-router-af)#net 192.168.54.5 0.0.0.0
*Sep 12 16:32:22.625: %DUAL-5-NBRCHANGE: IP-EIGRP(1) 14: Neighbor 192.168.54.4 (Serial0/0/0.1) is up: new adjacency
Rack1R5(config-router-af)#redistribute bgp 1 metric 100 100 255 1 1500
Rack1R5(config-router-af)#router bgp 1
Rack1R5(config-router)#address-family ipv4 vrf Green
Rack1R5(config-router-af)#redistribute eigrp 14

Now lets look at the VPNv4 routes on R5:

Rack1R5#sh ip bgp vpnv4 vrf Green
BGP table version is 27, local router ID is 220.61.253.5
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
Route Distinguisher: 1:14 (default for vrf Green)
*>i192.168.21.0 220.61.253.2 0 100 0 ?
*> 192.168.54.0 0.0.0.0 0 32768 ?
*>i192.168.253.1/32 220.61.253.2 2297856 100 0 ?
*> 192.168.253.4/32 192.168.54.4 2297856 32768 ?
Rack1R5#

Looks good – lets check the routing table on R4:

Rack1R4#sh ip route
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
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

D 192.168.21.0/24 [90/2681856] via 192.168.54.5, 00:10:53, Serial0/0/0.1
C 192.168.54.0/24 is directly connected, Serial0/0/0.1
192.168.253.0/32 is subnetted, 2 subnets
C 192.168.253.4 is directly connected, Loopback0
D 192.168.253.1 [90/2809856] via 192.168.54.5, 00:10:53, Serial0/0/0.1
Rack1R4#

We have routes to R1 loopback on R4, and if you notice is an internal route – AD of 90.

Lets try a PING and test connectivity:

Rack1R4#p 192.168.253.1 so l0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.253.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.253.4
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 112/114/116 ms
Rack1R4#

Looking good and that is all set!

Lets cover another interesting part of MPLS and EIGRP.

What would happen if you had a leased line bewteen two sites as well as an MPLS conenction, hmm. How would you prevent a routing loop from occoring or a sub-optimal path from happening? That is where SoO come into play.

So, lets configure VRF Blue for EIGRP AS 36 as well as the PEs R2 and R5 to redistribute the routes. After we get the basic configuration done and verified, we will then bring up a link between R3 and R6 and take care of the potential problems.

R3
Rack1R3(config)#router eigrp 36
Rack1R3(config-router)#network 192.168.23.3 0.0.0.0
Rack1R3(config-router)#network 192.168.253.3 0.0.0.0
Rack1R3(config-router)#no auto-summary

R2
Rack1R2(config)#router eigrp 1
Rack1R2(config-router)#address-family ipv4 vrf Blue
Rack1R2(config-router)#no auto-summary
Rack1R2(config-router)#autonomous-system 36
Rack1R2(config-router)#network 192.168.23.2 0.0.0.0
Rack1R2(config-router)#redistribute bgp 1 metric 100 100 100 100 1500
Rack1R2(config)#router bgp 1
Rack1R2(config-router)#address-family ipv4 vrf Blue
Rack1R2(config-router-af)#redistribute eigrp 36

R5
Rack1R5(config)#router eigrp 1
Rack1R5(config-router)#address-family ipv4 vrf Blue
Rack1R5(config-router)#no auto-summary
Rack1R5(config-router)#network 192.168.56.5 0.0.0.0
Rack1R5(config-router)#autonomous-system 36
Rack1R5(config-router)#redistribute bgp 1 metric 100 100 100 100 1500
Rack1R5(config)#router bgp 1
Rack1R5(config-router)#address-family ipv4 vrf Blue
Rack1R5(config-router-af)#redistribute eigrp 36

R6
Rack1R6(config)#router eigrp 36
Rack1R6(config-router)#no auto-summary
Rack1R6(config-router)#network 192.168.56.6 0.0.0.0
Rack1R6(config-router)#network 192.168.253.6 0.0.0.0

So, lets take a look at R6 and see if we see R3′s routes as well as can ping from loopback to loopback:
Rack1R6#sh ip route
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
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

C 192.168.56.0/24 is directly connected, Serial0/0/0.1
D 192.168.23.0/24 [90/2681856] via 192.168.56.5, 00:10:39, Serial0/0/0.1
192.168.253.0/32 is subnetted, 2 subnets
C 192.168.253.6 is directly connected, Loopback0
D 192.168.253.3 [90/2809856] via 192.168.56.5, 00:10:39, Serial0/0/0.1
Rack1R6#
Rack1R6#p 192.168.253.3 so l0 t 1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.253.3, timeout is 1 seconds:
Packet sent with a source address of 192.168.253.6
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 112/114/116 ms
Rack1R6#

Ahh, now lets us add some complexitiy to the design. We will add a WAN connection directly between R3 and R6, creating a back-door link in the network.

Ok, lets get the serial link up and running:

R3:
Rack1R3(config)#int ser 0/0/0.2 p
Rack1R3(config-if)#ip add 192.168.36.3 255.255.255.0
Rack1R3(config-if)#frame-relay interface-dlci 306

R6:
Rack1R6(config)#interface Serial0/0/0.2 point-to-point
Rack1R6(config-if)#ip address 192.168.36.6 255.255.255.0
Rack1R6(config-if)#frame-relay interface-dlci 603

Now a quick PING interface to interface so that we can verify that it is working:

Rack1R6#p 192.168.36.3 t 1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.36.3, timeout is 1 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 56/56/56 ms
Rack1R6#

Good, now lets add it to EIGRP and see what happens. But before we do, lets take a look at the routing tables on R3:
Rack1R3#sh ip route
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
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

D 192.168.56.0/24 [90/2681856] via 192.168.23.2, 00:00:03, Serial0/0/0.1
C 192.168.23.0/24 is directly connected, Serial0/0/0.1
C 192.168.36.0/24 is directly connected, Serial0/0/0.2
192.168.253.0/32 is subnetted, 2 subnets
D 192.168.253.6 [90/2809856] via 192.168.23.2, 00:00:03, Serial0/0/0.1
C 192.168.253.3 is directly connected, Loopback0
Rack1R3#

Ok, so right now the route to the loopback of R6 is via R2, the PE Router. So, lets get this link in EIGRP

R6:
Rack1R6(config)#router eigrp 36
Rack1R6(config-router)#net 192.168.36.6 0.0.0.0

R3:
Rack1R3(config-fr-dlci)#router eigrp 36
Rack1R3(config-router)#network 192.168.36.3 0.0.0.0
*Sep 16 02:07:41.304: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 36: Neighbor 192.168.36.6 (Serial0/0/0.2) is up: new adjacency

Now, lets take a look at the routing table on R3.
Rack1R3#sh ip route
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
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

D 192.168.56.0/24 [90/2681856] via 192.168.36.6, 00:00:47, Serial0/0/0.2
[90/2681856] via 192.168.23.2, 00:00:47, Serial0/0/0.1
C 192.168.23.0/24 is directly connected, Serial0/0/0.1
C 192.168.36.0/24 is directly connected, Serial0/0/0.2
192.168.253.0/32 is subnetted, 2 subnets
D 192.168.253.6 [90/2297856] via 192.168.36.6, 00:00:47, Serial0/0/0.2
C 192.168.253.3 is directly connected, Loopback0
Rack1R3#

The route is now via the point-to-point link. Lets change this so that the preferred path is via the MPLS network. To do this we will need to tweak the interface metrics – so lets change the delay on both ends to 50000 usecs. But first we should look at our existing delay before changing it.

R3:
Rack1R3#sh int ser 0/0/0.1
Serial0/0/0.1 is up, line protocol is up
Hardware is GT96K Serial
Internet address is 192.168.23.3/24
MTU 1500 bytes, BW 1544 Kbit/sec, DLY 20000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation FRAME-RELAY
CRC checking enabled
Last clearing of “show interface” counters never

Rack1R3#sh int ser 0/0/0.2
Serial0/0/0.2 is up, line protocol is up
Hardware is GT96K Serial
Internet address is 192.168.36.3/24
MTU 1500 bytes, BW 1544 Kbit/sec, DLY 20000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation FRAME-RELAY
CRC checking enabled
Last clearing of “show interface” counters never
Rack1R3#

Now, lets change that delay:

Rack1R3(config-subif)#int ser 0/0/0.2
Rack1R3(config-subif)#delay 5000
Rack1R3(config-subif)#do show int ser 0/0/0.2
Serial0/0/0.2 is up, line protocol is up
Hardware is GT96K Serial
Internet address is 192.168.36.3/24
MTU 1500 bytes, BW 1544 Kbit/sec, DLY 50000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation FRAME-RELAY
CRC checking enabled
Last clearing of “show interface” counters never
Rack1R3(config-subif)#

There, that is set to 50000 usec now.

R6
Rack1R6(config)#int ser 0/0/0.2
Rack1R6(config-subif)#delay 5000
Rack1R6(config-subif)#do show int ser 0/0/0.2
Serial0/0/0.2 is up, line protocol is up
Hardware is GT96K Serial
Internet address is 192.168.36.6/24
MTU 1500 bytes, BW 1544 Kbit/sec, DLY 50000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation FRAME-RELAY
CRC checking enabled
Last clearing of “show interface” counters never
Rack1R6(config-subif)#

That side is done as well.

Now, lets look at the routing table on R3:

Rack1R3#sh ip route
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
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

D 192.168.56.0/24 [90/2681856] via 192.168.23.2, 00:00:52, Serial0/0/0.1
C 192.168.23.0/24 is directly connected, Serial0/0/0.1
C 192.168.36.0/24 is directly connected, Serial0/0/0.2
192.168.253.0/32 is subnetted, 2 subnets
D 192.168.253.6 [90/2809856] via 192.168.23.2, 00:00:52, Serial0/0/0.1
C 192.168.253.3 is directly connected, Loopback0
Rack1R3#

Good. We are now using the MPLS link for the connectivity.

Site of Origin, or SoO, is an extended BGP community that provides a way to identify routes that have originated from a site and prevents the re-advertisement of that route back to the source. This allows us to filter MPLS VPN traffic and prevent routing loops from occuring in mixed networks that contain both MPLS VPNs an backdoor links.

Lets get it configured on the PE routers and I will explain what we are doing.

R5
First thing to do is create a route-map
Rack1R5(config)#route-map SoO_36 permit 10
Now we can set the extended community attribute, here 36:5 (AS 36 PE 5 is the numbering I used)
Rack1R5(config-route-map)#set extcommunity soo 36:5
Now we need to apply it to the interface facing R6. The command for this is vrf sitemap
Rack1R5(config-route-map)#int ser 0/0/0.2
Rack1R5(config-subif)#ip vrf sitemap SoO_36
Rack1R5(config-subif)#
As you can see, the EIGRP neighbors bounce while the sitemap is applied.
*Oct 7 21:11:11.875: %DUAL-5-NBRCHANGE: IP-EIGRP(2) 36: Neighbor 192.168.56.6 (Serial0/0/0.2) is down: SoO changed
Rack1R5(config-subif)#
*Oct 7 21:11:13.111: %DUAL-5-NBRCHANGE: IP-EIGRP(2) 36: Neighbor 192.168.56.6 (Serial0/0/0.2) is up: new adjacency
Rack1R5(config-subif)#

R2
Rack1R2(config)#route-map SoO_36 permit 10
Rack1R2(config-route-map)#set extcommunity soo 36:2
Rack1R2(config)#int ser 4/0.2
Rack1R2(config-subif)#ip vrf sitemap SoO_36
Rack1R2(config-subif)#
*Oct 7 19:44:42.981: %DUAL-5-NBRCHANGE: IP-EIGRP(1) 36: Neighbor 192.168.23.3 (Serial4/0.2) is down: SoO changed
Rack1R2(config-subif)#
*Oct 7 19:44:47.081: %DUAL-5-NBRCHANGE: IP-EIGRP(1) 36: Neighbor 192.168.23.3 (Serial4/0.2) is up: new adjacency
Rack1R2(config-subif)#

Now lets check to see if the SoO is there – first the PE routers:

R2
Rack1R2#sh ip bgp vpnv4 all 192.168.253.3
BGP routing table entry for 2:36:192.168.253.3/32, version 48
Paths: (1 available, best #1, table Blue)
Advertised to update-groups:
1
Local
192.168.23.3 from 0.0.0.0 (220.61.253.2)
Origin incomplete, metric 2297856, localpref 100, weight 32768, valid, sourced, best
Extended Community: SoO:36:2 RT:2:36
Cost:pre-bestpath:128:2297856 (default-2145185791) 0×8800:32768:0
0×8801:36:640000 0×8802:65281:1657856 0×8803:65281:1500
mpls labels in/out 28/nolabel

R5
Rack1R5#sh ip bgp vpnv4 all 192.168.253.6
BGP routing table entry for 2:36:192.168.253.6/32, version 19
Paths: (1 available, best #1, table Blue)
Flag: 0×820
Advertised to update-groups:
1
Local
192.168.56.6 from 0.0.0.0 (220.61.253.5)
Origin incomplete, metric 2297856, localpref 100, weight 32768, valid, sourced, best
Extended Community: SoO:36:5 RT:2:36
Cost:pre-bestpath:128:2297856 (default-2145185791) 0×8800:32768:0
0×8801:36:640000 0×8802:65281:1657856 0×8803:65281:1500
mpls labels in/out 29/nolabel

There we go, route is being tagged with an SoO value of 36:5 or 36:2 depending on which router originated it.

Now one last thing to check, lets too at EIGRP on R3 for R6 loopback that we are learning from R2:

Rack1R3#sh ip eigrp topology 192.168.253.6/32
IP-EIGRP (AS 36): Topology entry for 192.168.253.6/32
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 2809856
Routing Descriptor Blocks:
192.168.23.2 (Serial0/0/0.1), from 192.168.23.2, Send flag is 0×0
Composite metric is (2809856/2297856), Route is Internal
Vector metric:
Minimum bandwidth is 1544 Kbit
Total delay is 45000 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 2
Extended Community: SoO:36:5

As you can see, we have the SoO Extended Community attribute in EIGRP, this if we re-advertise that to R5 it will be filtered.

I just got my invitation to the next Tech Field Day, well actually Network Field Day #2, and I cannot tell you how excited I am, as well as humbled to be asked to attend.

My first experience with Tech Field Day was back in February of this year when I attended Tech Field Day #5. That event was more data center focused and was something that I will never forget. I learned quite a bit about a lot of technologies and companies that I was not overly familiar with. It was amazing to see how far some of the technology has come so fast, it was just mind melting. There where some topics that where right up my alley with regards to expertise, and those I learned even more about. It was an experience that I was hoping I would get a chance to experience again, and thankfully I will.

This event will be a Networking focused event and is being held on October 27 and 28 in lovely San Jose, CA. Some of the already named vendors who will be presenting include Brocade, Cisco, Embrane, Gigamon, Juniper, and NEC. Those are some BIG names in the networking world, and knowing what we saw and learned at TFD5, I can tell you that this one is going to be awesome! What is even more impressive to me is the list of delegates at this event – these are people and peers who I have great respect for. The list includes:

	Kurt Bales	Network Janitor	@NetworkJanitor
	Ethan Banks	PACKETattack	@ECBanks
	Tony Bourke	The Data CenterOverlords	@TBourke
	Brandon Carroll	BrandonCarrollGlobalConfig	@BrandonCarroll
	Greg Ferro	EtherealMind Packet Pushers	@EtherealMind
	Jeremy L Gaddis	Evil Routers	@JLGaddis
	Tom Hollingsworth	The Networking Nerd	@NetworkingNerd
	Ivan Peplnjak	Cisco IOS Hints and Tricks	@IOSHints
	Mrs. Y	Packet Pushers	@MrsYisWhy

This is shaping to be an epic event and one that I am very excited to be invited to attend. I cannot wait to see what I learn as well as what I will be able to share as well.

A special thank you for the invitation goes to Stephen Foskett, his team, and a humble thank you to my peers.