Quick-Series 29 : Mx – Bridge-Domain – Using Vlan-id None ? –

No Comments


Continuing on Bridge-Domains on Mx, I came across using vlan-id “none” and initially was surprised by this knob, I mean we create bridge-domain based on a Vlan and associate / segregate traffic based on Vlan-id.

Lets explore a use case or a remote scenario where this might come in handy.

Let us say you have customers with different vlan’s and you are about to be in merger and provide a common Layer-3 IP. Obviously, if you are in a situation where you have them on your sub-interfaces, you cannot have same vlan-id for two Sub-interfaces.

Let see what Vlan-id None can do here




Looking closely at the configuration, we see that vlan-id none has been used instead of being specific, but as you see the interfaces, they are clearly in vlans 101 and 102. So, how does thisΒ  work ?


There you go, there is a Pop in the inbound direction of the interface, a POP action popping out Vlan and the return traffic is now having PUSH action, hence traffic coming into bridge-domain will not care with what Dot1q tag the packet is coming-in.


Lets initiate a Ping and see if this works from two customer ends who are in different Vlans.


There you Go



Rakesh M

Virtual Switch Instance – vMX



Virtual-Switch instance was alwaysΒ  a fascination for me, just for a simple fact that you could turn a Router to Bridge/Switch everything. Although there are many advantages and applications, I quickly wanted to write up the Lab scenario which I have Done. I always prefer seeing some simple things first and then may be do a deep-dive about the feature.

Requirement- Router-1 / 2/ 3 are all attached to VMX , they have to ping to each other through vMX and this has to happen via Instance Virtual-Switch. Now, someone who already knows about default-switch / Bridge-domain could have said why not use these, well this Post is going to Expand when we revisit of having Why we needed Virtual-Switch advantage in first place.


Below is the Topology


Ge-0/0/0 is connected to R1 , Ge-0/0/1 connected to R2, Ge-0/0/3 Connected to R3. Let see what we need to configure at a basic level for this to work



So far so Good, whats Next, as per the requirement we were to create a Virtual-Switch Instance


Everything is fine, but looks like communication is not yet established, the reason is simple, we have used something called Enterprise-Style definition. To put it simply, we have to configure a Bridge-Domain for these interfaces to be associated with Bridge-Domain of Vlan-id 100. There is something called Learning Domain where it gets associated to Bridge-Domain, but that is not the post about.

Lets Create a Bridge-Domain quickly for Vlan-id 100 and see if it changes anything, please do note the bridge-domain will now be the part of the Instance and here comes the beauty of the virtual-switch, you could have completely a different virtual-switch with same Vlan and it just works fine, re-call the Idea of VRFΒ  / Routing-Instance now πŸ˜‰



Lets look at the configuration again along with Mac-Table generation



Rakesh M







Quick Scenario -3 – Bgp Local-as

No Comments



3rd post in the quick series is about BGP local-as

BGP Local-AS

“The local-AS feature allows a router to appear to be a member of a second Autonomous systems (AS), in addition to its real AS. This feature can only be used for true eBGP peers. You cannot use this featureΒ  for two peers that are members of different confederation sub-ASs”


Requirement – R1 needs to peer with R2 with As number 400 while all other Routers to peer with R2 should use a AS number of 200



As we can see, R2 is acting as Local-as 400 for R1 and AS 2 for R3






Quick Scenario -2 – Bgp Communities – (no-advertise)

No Comments


2nd post in the quick series is about BGP community no-advertise

Community – No-Advertise

“No-Advertise is similar to No-export, While no-export does not export routes to another AS, this goes further and it will not export route to both ebgp or ibgp neighbors as well.”

Requirement – Make sure R1 advertises its routes to R2, and R2 should not advertise the routes to either EBGP or IBGP neighbors



Before confiuring anything





access-list 99 permit host

route-map NO-ADV-COMM permit 10
match ip address 99
set community no-advertise

router bgp 100
nei route-map NO-ADV-COMM out










Quick Scenario -1 – Bgp Communities – (no-export)

No Comments


This will be a series of posts in which i shall be posting some quick scenario labbings. Mostly i have designed these so that I can relate to some stuff which i do not often use, nevertheless will blog all small topics

Community – No-export

“NO-EXPORT is commonly used within an AS to instruct routers not to export a prefix to eBGP neighbors. For instance, subnets of a larger block can be advertised to influence external AS best-path selection, and those not required for this traffic engineering purpose may be tagged NO-EXPORT to prevent them from being leaked to the Internet (and thus contributing to unnecessary global routing table growth). If a neighboring AS accepts this community, it can be used to selectively leak more specifics for traffic engineering but limit their propagation to just one AS.”

Requirement – R1 has its loopback advertised to R3 via BGP. Make sure the advertisement stays within the AS and should not go to another AS Router in this Case R3

no-export scenario

Before community addition – Routing Table of R3


AS we can see below route is not seen R3.



Rakesh M

Close Bitnami banner